DevOps, CI/CD and Automation

Hello,

I'm new to developing with Oracle, I'm talking to a db via ODBC.
I am waiting to hear from the People Upstairs if I can use the Oracle developers account thing to post bugs, but it looks like it will be a long wait.

If this is not the right place to post bugs, can someone please post it for me to the right spot or tell me how I can do so.


On to the bug, it is in regards to calling:
SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_ARRAY_SIZE, (SQLPOINTER)num_rows, 0);
etc etc...
SQLFetchScroll(etc);
(note I have not specified the type for num_rows).

I am using ODBC driver Oracle in OraClient11g_home1 version 11.02.00.01


The specs (http://msdn.microsoft.com/en-us/library/windows/desktop/ms712631(v=vs.85).aspx) state:
An SQLULEN value that specifies the number of rows returned by each call to SQLFetch or SQLFetchScroll. It is also the number of rows in a bookmark array used in a bulk bookmark operation in SQLBulkOperations. The default value is 1.
If the specified rowset size exceeds the maximum rowset size supported by the data source, the driver substitutes that value and returns SQLSTATE 01S02 (Option value changed).

So, the call above should be able to look like this:
SQLULEN num_rows = SEE_BELOW;
SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_ARRAY_SIZE, (SQLPOINTER)num_rows, 0);
... SQLFetchScroll(etc);

There are few edge-cases here,
first, if you set num_rows=0, then the call to SQLFetchScroll will send the program into an infinite loop.
So, that is easy to avoid, but...

second, if you set num_rows=65536 or greater, then the call to SQLFetchScroll will ALSO send the program into an infinite loop. 65535 works fine.

So my guess is that there is an internal limit on the number of rows, ie Oracle is assuming the num_rows is of type SQLUSMALLINT (ie 16-bit integer)

According to the spec, the Oracle driver should NOT screw up, but instead should adjust the number of rows to an acceptable number, and return SQLSTATE 01S02.


Kind Regards,
Paul