I have experienced the same problem.. My PHP system is Windows XP running IIS and PHP 4.2.0. against a Windows 2K Server with MS-SQL 7.0.

I worked around it by closing the connetion and the requerying... The odbc_num_rows also fails... and I had to do a loop of odbc_fetch_row to count the rows in the recordset, then close the connection, then requery.  

The OpenSource program "WebCalendar" also isn't working with ODBC in 4.2.0 in a Windows environment with SQL Server (can't speak for anything else)... it uses the odbc_fetch_array command...and that too seems to be failing without any error messages.

nothing has changed to the odbc_fetch_row function in the last... 3 or 4 releases.  Can you please post a sample script, and a copy of a test schema (and data) to reproduce this problem.

If any of the other 12 respondents can produce code to demostrate, it will help.. mine is buried in an complex applications, and I will have to develop a demo scenario.  I can tell you everthing worked fine on PHP 4.1.X, and broke when we upgraded to 4.2.X  Only after we traced it did we find that the direct row specification on the ODBC_FETCH_ROW command was being ignored, and several other functions that would use similiar direct row addresses.  Perhaps it was a compile error... I can't say.  But it will take me a while to put together a set of demo functions and database schema...

Here is pysudocode for an example script that will casue this error.

$c=odbc_connect("some source", "uname", "pass" ); 
$res = odbc_exec($c,"some SQL statement");
if (!odbc_fetch_row($res))      // check if there are results
  {
  //   do something
  }
else
  {
    odbc_fetch_row($res,0);  // reset results <<-- this is what doesn't work
    while (odbc_fetch_row($res))
      {
        // loop through results
      }
  }
what happens in this expample is that the pointer on teh $res resource is advanced when the odbc_fetch_row() function is called in the if statement.  It is then advanced when called again in the while statement and the first row gets lost.  This happens because the odbc_fetch_row($res,0) does not move the pointer back to 0.  In versions of PHP prior to 4.2.1 odbc_fetch_row($res,0) worked properly.  Only after 4.2.1 has it become broken.  I had to write twice as much code to get arround this and I run into this quite often.  I had to rewrite quite a few functions becasue of this bug.  

- Anthony

"nothing has changed to the odbc_fetch_row function in the last... 3 or 4 releases"
Ok but the script below work fine i php 4.1.2, but dies in 4.2.0 and 4.2.1

function odbc_record_count($sql_id, $CurrRow = 0) {
    $NumRecords = 0;
    odbc_fetch_row($sql_id,0);
    while (odbc_fetch_row($sql_id)) {
        $NumRecords++;
    }
    
    if( !odbc_fetch_row($sql_id, $CurrRow)) die("odbc_record_count - odbc_fetch_row($CurrRow) failed");
    return $NumRecords;
}

btw odbc_num_rows still dont work properly

1) Please realize that register_globals is turned off in PHP 4.2.x

2) Can you please provide a full sample script to reproduce the problem?  The snippit you've shown doesn't really help as it doesn't show the full process for the code being used.  

Sorry that last message is more for gory@alaphsoft-bg.com 

This works for me in 4.2.1 and a recent pull from CVS.  

Whether it works for you or not.. there are 14 people who all said they can reproduce this error.  It worked fine under 4.1, and only broke when we upgraded to 4.2. If so many people experienced the same problem, then there is obviously something wrong here.

I have heard from various people that they have had issues with this.  I've tested it with two ODBC drivers, against 2 different databases (a total of 4 different tests).  I cannot reproduce this on my local tests.  The numbers all seem to be correct with any test that I do.  If I cannot reproduce this, I cannot debug this problem.  

It may be that this a problem specific to Windows, to which I can say that Win2k does have a problem where one of the recent service packs breaks ODBC.  The solution to this was to re-install the latest MDAC from Microsoft.  Unfortunately I do not remember the proper SP number so I cannot comment on that.  Nor do I have acccess to a Windows based machine to do any kind of testing with/against.  

I have experienced the same problem again in PHP 4.2.3

[24 Jun 10:34pm] kalowsky@php.net says 
"It may be that this a problem specific to Windows, to which I can say
that Win2k does have a problem where one of the recent service packs
breaks ODBC.  "
Actualy my system is 
Linux (kernel 2.4.18)
iODBC driver manager
database is Sybase SQLAnywhere 8.0 for Linux

just try to execute a simple select and run a function odbc_record_count agains a result