RE: [PHP-DEV] PHP 4.0 Bug #9261: odbc to an oracle 'view' fails

Hi Andreas, Generally cursors won't be used with views, as this doesn't make a lot of sense. :) 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. Best regards, Andrew -------------------------------------- Andrew Hill - OpenLink Software Director Technology Evangelism eBusiness Infrastructure Technology http://www.openlinksw.com > -----Original Message----- > From: Andreas Karajannis [mailto:karajannis@mediaworx.com] > Sent: Wednesday, February 14, 2001 2:03 PM > To: ahill@openlinksw.com > Cc: bengt.nilsson@aerotechtelub.se; php-dev@lists.php.net > 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 > > -- > Andreas Karajannis > mediaworx berlin AG > > Fon (0 30) 2 75 80 - 266 > Fax (0 30) 2 75 80 - 200 > >