Re: [PHP-DEV] Pear::db and odbc issue
See: http://www.php.net/manual/en/function.odbc-num-rows.php "For a SELECT clause this _can_ be the number of rows available. Note: Using odbc_num_rows() to determine the number of rows available after a SELECT will return -1 with many drivers." -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, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] odbc problems in 4.2
Dan Kalowsky wrote: > Hi Ryan, > > Okay did a little looking over the odbc_fetch_row code, and it should > reset the result->fetched to whatever the second argument (if one is > provided) is. This variable is how the ODBC result system handles where > it currently is in the cache. Now the catch is that odbc_result checks > this value, and if it's set to 0 re-fetches the results. > This should be perfectly ok, just as if you start with a fresh resultset. Row # 0 doesn't contain data. > So in otherwords the code sample you sent should work, provided that the > $rs is a valid result. I'm having some local DB access/ODBC issues so I > cannot test it right at the moment. I'm working on fixing that. > > > > On Wed, 24 Apr 2002, Ryan Jameson (USA) wrote: > > >>If this is easy for anyone could someone verify that: >> >>odbc_fetch_row($rs,0); >> >>...does not reset the result set in version 4.2? From what I can tell >>it doesn't work at all. I want to be certain that we cannot upgrade to >>4.2. If someone has another way to reset an ODBC result set I'd love to >>hear about it. It's done in a central core function, but is necessary in >>a plethora of scripts. The result set comes from the MS SQL Server driver >>(shhh... I tried to get them to use MySQL ... they are scared of free >>stuff. I'm just glad they let me use PHP). Thanks! >> Just to clarify: The odbc module doesn't cache or refetch resultsets. Whether you're able to "reset" a resultset depends on the odbc driver or driver manager you use (And how PHP was compiled, see below). If the driver doesn't support so called "scrollable cursors", some Driver Managers (afaik unixODBC and the standard MS Windows DM do) provide support for this via a cusror library that caches resultsets and emulates scrolling cursors. My guess is that the PHP 4.2 you've tried was wasn't compiled with HAVE_SQL_EXTENDED_FETCH (so only the simple SQLFetch that can only move forwards gets used; the rownum parameter is ignored in this case) or that your DM wasn't configured to use it's cursor library. -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, visit: http://www.php.net/unsub.php
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 -- 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]
