5

We are reading data from a CLOB into an std::vector via OCCI. The simplified code looks as follows:

oracle::occi::Clob clob = result.getClob( 3 );
unsigned len = clob.length();
std::vector< unsigned char > result( len );
unsigned have_read = clob.read( len , result.data() , len );

This yields the error ORA-32116, saying that the buffer size (3rd argument of read) should be equal or greater than the amount of data to be read (1st argument of read). This condition is apparently held.

After increasing the buffer size to 4*len:

unsigned have_read = clob.read(len , result.data() , 4 * len);

the operation is performed properly. So far, the values of have_read and len were always identical.

Is there an undocumented extra amount of space needed for the buffer? Or are complete pages needed?

We are using "Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit".

Any clarification on the topic is welcome.

Ben
  • 51,770
  • 36
  • 127
  • 149

1 Answers1

2

I suspect that you've got multi-byte characters in your CLOB.

According to the documentation clob.length() "returns the number of characters in the CLOB" whereas the buffsize parameter of clob.read() states that "valid values are numbers greater or equal to amt", which in turn says that it's "the number of bytes to be read."

In other words (and according to the documentation) you're passing the number of characters to clob.read() when it's expecting the number of bytes. The fact that you're getting an error would suggest that the former is smaller than the latter.

The documentation suggests changing the buffer to be a utext, after setting the character set via setCharSetId() would fix it.

Alternatively, if you've got multi-byte characters and don't need to do any character representation (no idea), it might be worth working with BLOBs instead; blob.length() returns the number of bytes.

Ben
  • 51,770
  • 36
  • 127
  • 149
  • Note that `utext` occupies 2 bytes, while characters can be either 3 or 4 bytes. Thus, the allocated buffer may not be enough anyway. – Marat Gareev Jan 03 '23 at 21:06