php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #32486 odbc_fetch_into returns wrong data
Submitted: 2005-03-29 16:58 UTC Modified: 2005-08-15 01:00 UTC
From: tho at e-dict dot net Assigned:
Status: No Feedback Package: Adabas-D related
PHP Version: 4CVS-2005-05-17 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: tho at e-dict dot net
New email:
PHP Version: OS:

 

 [2005-03-29 16:58 UTC] tho at e-dict dot net 
Description:
------------
Sometimes after odbc_fetch_into($query, $row) $row contains parts of data from the previous fetched row. For now I'm not able to reproduce this behavior reliably, it just happens once in a while. 
What happens is that if the data of the previous row is longer than in the current, the result contains '$currentdata\0$somepreviousdata', e.g.
previous row: "tho@somedomain.net"
current row:  "tho@e-dict.net"
results in
"tho@e-dict.net\0net"
IOW the field is as long as the data in the previous row, contains a \0 terminator after the field content and then the rest of the previous field.
This also happens if a unset($row) is done before calling odbc_fetch_into()

Reproduce code:
---------------
N/A

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-05-11 16:30 UTC] tho at e-dict dot net 
Tried php4-STABLE-200501211130 and still get wrong results. The \0 issue described before could not be reproduced since the field in the second line was longer then in the first line. But I found out, that in all cases the \0 issue occoured, there was a date field right before the string field and this date field contained the data from the previous line. e.g.
1992-09-09, tho@somedomain.net
1960-01-09, tho@e-dict.net
results in
1992-09-09, tho@somedomain.net
1992-09-09, tho@e-dict.net\0net
 [2005-05-17 09:10 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
 [2005-06-06 18:12 UTC] tho at e-dict dot net 
still happens with php4-STABLE-200505171238
 [2005-06-08 16:03 UTC] nick dot telford at gmail dot com 
Can you provide more information on how this is occuring? The script that is causing it would be helpful, along with a guess at roughly how often this problem occurs.

I have so far failed to replicate this bug on PHP4.3.11, i've written a script to get some test data from a local ODBC db 100 times and detect if the overflow is present. Running it now.
 [2005-06-08 16:05 UTC] nick dot telford at gmail dot com 
Also, since it's ODBC, we'll need to know the database you're using and the version. It's quite possible that the database itself is returning invalid data and PHP isn't compensating for it.
 [2005-06-08 18:01 UTC] tho at e-dict dot net 
We're using Adabas with kernel version 12.01.26. What the script basicly does is
$dbhandle = odbc_pconnect();
odbc_autocommit($dbhandle, 0);
odbc_rollback( $dbhandle );
$queryid = odbc_exec($dbhandle, $sql);
while (odbc_fetch_into( $queryid, $row )) {
}
odbc_commit($dbhandle);

The overflow occours once in 2-10 days with abound 50 seeks a day. And of course the database itself could be responsible - I just started tcpdump to see whether the db or php causes the problem.
 [2005-06-14 14:39 UTC] tho at e-dict dot net 
Seems like database is not causing the problem. The tcpdump looks okay.
 [2005-08-07 14:27 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

And try with the new PDO ODBC driver.
 [2005-08-15 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Dec 27 01:01:28 2024 UTC