PHP interrogates ODBC drivers, to see whether the driver supports the SQLExtendedFetch?() API call. If that support is present, PHP SQL resultset functions all request a Dynamic (or Bi-Directional Scrollable) Cursor, regardless of any other considerations.
All SQL queries made using a Dynamic Cursor requires that the SQL table in question have an ODBC-compliant primary key defined (an index is insufficient, whether unique or not).
Additionally, the OpenLink? cursor library does not support all queries on scrollable cursors, even when a primary key is defined. Some queries that OpenLink? Support have discovered can be problematic use aggregate functions, have a 'group by' clause, or call stored procedures.
Error messages include --
An upcoming update to OpenLink? drivers (Release 6.x, after September 2006) will resolve this issue for good and all, without any need for recompilation of PHP, nor changes to the database schema.
If you are encountering these problems before this update, and cannot modify the underlying database schema, you will need to modify your PHP source and recompile.
For PHP 4.2 and below, you can have PHP disable server-side cursor functionality in all SQL statements by making a change in PHP's ODBC handling source.
Edit the PHP source file ext/odbc/php_odbc.c
Change the last two instances of SQL_CURSOR_DYNAMIC to SQL_CURSOR_FORWARD_ONLY
For PHP 4.2 and above, you can make this behavior take effect at query-time, by preventing all use of the SQLExtendedFetch?() API call.
Edit the PHP source file ext/odbc/php_odbc_include.h
Around line 96 there will be a block of #ifdef and #define statements pertaining to iODBC . Replace the one that says
#define HAVE_SQL_EXTENDED_FETCH 1
with one that says
#undef HAVE_SQL_EXTENDED_FETCH
If none of the above suggestions solves the problem, please open a support case, and forward the page source with an ODBC trace showing the page's execution, referencing your case number in the subject header, to technical.support@openlinksw.com.