sqlipFetchRowsInBuffer
- Last Updated: May 12, 2026
- 4 minute read
- OpenAccess SDK
- Version 8.1
- Documentation
This method fetches multiple rows of data from the current cursor position into the supplied buffer and advances the cursor.
If all available records have been added to the buffer, return OADS_NO_DATA. If the buffer is filled before end of a result set, then return OADS_BUFFER_FULL to indicate that more rows are available, but the current buffer is full. The buffer may be full because the specified number of rows have been added or because the memory buffers passed into this method have been filled.
Use of this method is enabled by setting the ServiceJavaIPUseBulkFetch service attribute to Enable. See the OpenAccess SDK Administrator’s Guide for information about enabling and controlling the memory.
This method is used only for data rows. For schema rows, the existing sqlipFetchRow and sqlipGetColval methods are used.
public Object[] sqlipFetchRowsInBuffer(
ByteBuffer pBuffer,
char[] pCharData,
xo_int piNumResRows,
xo_int piStrDataLen,
xo_int piStatus);
Parameters for sqlipFetchRowsInBuffer
| Parameter | Type | Description |
| INPUT | ||
| pBuffer | ByteBuffer | Byte buffer into which the NULL/not NULL indicator, lengths of string data, and the values for primitive types are to be added. The size of this buffer is controlled by the ServiceJavaIPByteBufferSize service attribute. |
| pCharData | char[ ] | char array into which data for CHAR, and VARCHAR, are added. Initially it points to the beginning. The size of this buffer is controlled by the ServiceJavaIPStringBufferSize service attribute. |
| OUTPUT | ||
| piNumResRows | xo_int | Number of rows added to the buffer. |
| piStrDataLen | xo_int | Total length of CHAR and VARCHAR data written to the pCharData char array. |
| piStatus | xo_int | Status of the operation: OADS_BUFFER_FULL – indicates that the next block of rows have been added to the buffer. OADS_NO_DATA – all available rows have been added to the buffer or there are no rows to retrieve. OADS_ERROR – error fetching a row. |
| RETURN | ||
| Object[ ] | Array of objects for LONG data types. Each element represents a long column value. Each LONG column has one object element in the array. Your IP must create the array return to SDK. We expect char[ ] object for LONG_VARCHAR data type. We expect byte[ ] object for LONG_VARBINARY data type. If the result set includes no long data then return NULL. |
The ByteBuffer pBuffer is filled with column value indicator (NOT_NULL_INDICATOR or NULL_INDICATOR) and the primitive data for each column in sequence. For string data, you put a NULL_INDICATOR or NOT_NULL_INDICATOR byte followed by the string length in the ByteBuffer. The string data is appended to the pCharData. For LONG data, the null indicator byte followed by the length (if the data is not NULL) is placed in ByteBuffer and an object of type char[ ] or byte[ ] is placed in the Object[ ] return array.
The IP continues adding rows until the pBuffer or pCharData are filled, end of the record set is reached, or the number of rows requested has been added. At this time, the IP indicates whether the buffer is full or no data was available, and sets piNumResRows to the number of rows added to the buffer.
The following table shows how the data for the various column types is expected. The column types are specified in JDBC and the OpenAccess SDK XO type convention. The code assumes the following variables have been created before the fetching:
int iCharDataIndex = 0;
ArrayList LargeObjList = new ArrayList();
Defining Data for Column Types
| JDBC Data Type | OpenAccess SDK XO Type | Method for Adding the Value |
| TINYINT SMALLINT BIT |
XO_TYPE_SMALLINT | Short value. short sVal = rs.getShort(i); |
| INTEGER | XO_TYPE_INTEGER | int iVal = rs.getInt(i); |
| BIGINT | XO_TYPE_BIGINT | long lVal = rs.getLong(i); |
| REAL | XO_TYPE_REAL | float iVal = rs.getFloat(i); |
| FLOAT DOUBLE |
XO_TYPE_DOUBLE | double iVal = rs.getDouble(i); |
| NUMERIC DECIMAL CHAR VARCHAR |
XO_TYPE_NUMERIC XO_TYPE_NUMERIC XO_TYPE_[W]CHAR XO_TYPE_[W]VARCHAR |
String str = rs.getString(i); |
| LONGVARCHAR | XO_TYPE_[W]LONGVARCHAR | String str = rs.getString(i); |
| DATE | XO_TYPE_DATE | Date dtVal = rs.getDate(i); |
| TIME | XO_TYPE_TIME | Time tVal = rs.getTime(i); |
| TIMESTAMP | XO_TYPE_TIMESTAMP | Timestamp tsVal = rs.getTimestamp(i); |
| BINARY VARBINARY |
XO_TYPE_BINARY XO_TYPE_VARBINARY |
byte[] bData = rs.getBytes(i); bWasNull = rs.wasNull(); |
| LONGVARBINARY | XO_TYPE_LONGVARBINARY | byte[] bData = rs.getBytes(i); |
Note: Java character types can be mapped to XO_TYPE_CHAR or XO_TYPE_WCHAR. This does not impact how the Java layer returns data to the native layer, but it does impact conversions at the native layer.
If you map your character data types to XO_TYPE_CHAR, XO_TYPE_VARCHAR, or XO_TYPE_LONGVARCHAR, then at the native layer, OpenAccess SDK must convert from Unicode to multi-byte character. However, if you map it to Unicode data types (XO_TYPE_WCHAR, XO_TYPE_WVARCHAR, or XO_TYPE_WLONGVARCHAR), then the data is directly transferred to the client without any Unicode-to-ASCII conversion.
See also
- sqlipFetchRow
- sqlipGetColval
- See the OpenAccess SDK Administrator’s Guide for information about enabling and controlling the memory.