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 Karajannis
mediaworx berlin  AG

Fon (0 30) 2 75 80 - 266
Fax (0 30) 2 75 80 - 200

PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to