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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
