Generally cursors won't be used with views, as this doesn't make a lot of
That being said, the cursor model in PHP could certainly use some tweaking
to work with cursors.
I'll send you the source code of GTKBench, a GPLed tool we wrote that does
lots of database centric benchmarking tasks.
Among other things it allows testing all the cursor models, so should
provide a good example of the ODBC API implemented with regards to cursors.
Accounting for how GTKBench sets the cursors should give you an idea of how
we are setting cursor parameters in drivers.
Andrew Hill - OpenLink Software
Director Technology Evangelism
eBusiness Infrastructure Technology
> -----Original Message-----
> From: Andreas Karajannis [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 14, 2001 2:03 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] 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 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]