Joop... Here's some more info:

-----Original Message-----
From: Andreas Karajannis [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 24, 2002 5:16 PM
To: Dan Kalowsky
Cc: Ryan Jameson (USA); [EMAIL PROTECTED]
Subject: 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:
>>...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 Karajannis
mediaworx berlin  AG

Fon (0 30) 2 75 80 - 266
Fax (0 30) 2 75 80 - 200

PHP Database Mailing List (
To unsubscribe, visit:

Reply via email to