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

Andreas, > 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? I think it would be wise to give the PHP developer the power to set the cursor location/type as you can do in C, VB, Java, etc. One example of why this is good is that many drivers write their own cursor library which may not support certain queries (such as those with aggregate functions) on scrollable cursors. I see no reason not to leave the default PHP behavior as is (set to dynamic then look for Driver's default if not supported). However, giving the developer the power to change this seems to be a good idea for support for the most driver configurations possible. As I understand it, the "odbc_setoption" function already supports this?? From the manual, // 2. Option 0 of SQLSetStmtOption() is SQL_QUERY_TIMEOUT. // This example sets the query to timeout after 30 seconds. $result = odbc_prepare ($conn, $sql); odbc_setoption ($result, 2, 0, 30); odbc_execute ($result); So, a PHP author could feasibly do this themselves using similar syntax: $result = odbc_prepare ($conn, $sql); odbc_setoption ($result, 2, 6, 3); odbc_execute ($result); where the setoption line would set the Cursor to a static cursor. Hopefully the above method can achieve the flexibility we want... Regards, Stephen Schadt Technical Support Consultant OpenLink Software http://www.openlinksw.com XML & E-Business Infrastructure Technology Provider > > -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: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net > > >