Re: PHP 4.0 Bug #9261: odbc to an oracle 'view' fails

Andrew Hill wrote:

Hi, This error indicates that there is no index/primary key in a result set that the driver is attempting to read into a cursor. Adding a primary key to the table will fix this, or passing a different cursor type in will fix this - keyset driven cursors are essentially 'sliding windows' - they read a set of rows in, and then scroll back and forth. Upon reaching the end of the set, they grab the next keyset in the direction of scroll. On a related note, does anyone know to pass different cursor models in the select statement? There are essentially 5 cursor models supported by SQL, Static, Keyset, Mixed, Forward Scrollable, Bi-Directional Scrollable. PHP's cursor handling has always been a bit of a mystery to me - if anyone can point me towards the current implementation of it I will dig.

PHP tries to set the cursor type to Dynamic (or Bi-Directional Scrollable) if the driver supports SQLExtendedFetch. If a driver doesn't support this cursor model, the next best available model is substituted by the driver. This was to enable absolute positing in the resultset without bothering the user with choosing a cursor type. Unfortunately, there is currently no way to explicitly set the cursor type for a statement (I didn't myself really understand the ODBC cursor model at that point and was mainly focused on being able to scroll through a resultset). I could add another parameter to odbc_prepare/odbc_exec to set the cursor type. I'm unsure to what type the cursor should be set, if not specified. Either keep the existing behaviour and be backwards compatible or use the default static cursor provided. Any Opinions? -Andreas -- Andreas Karajannis mediaworx berlin AG Fon (0 30) 2 75 80 - 266 Fax (0 30) 2 75 80 - 200