php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #29324 Severe problems with NexusDB ODBC driver
Submitted: 2004-07-22 12:01 UTC Modified: 2005-01-26 01:00 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:1 (50.0%)
From: groenink at xs4all dot nl Assigned:
Status: No Feedback Package: ODBC related
PHP Version: 5.0.0 OS: Windows XP
Private report: No CVE-ID: None
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: groenink at xs4all dot nl
New email:
PHP Version: OS:

 

 [2004-07-22 12:01 UTC] groenink at xs4all dot nl
Description:
------------
Accessing a NexusDB database from PHP using the ODBC driver results in two problems, that cannot be reproduced using any other ODBC query tools:

(1) The columns returned by odbc_fetch_array() are not indexed by their column names, but by the values!!!

(2) Getting one row with odbc_fetch_array() is fine, but as soon as you ask for the second one, the web server complains about an access violation (both Apache and IIS).

Apparently the driver does something that the ODBC library in PHP doesn't expect, but most other windows programs think is fine.

The problem exists in PHP 4.3.7 as well as PHP 5.0.0.


Reproduce code:
---------------
$db = odbc_connect("nexusdb", "", "");


// Don't use "select *", it will crash immediately.
// This is something the other ODBC tools seem to
// know and deal with as well.
//
$result = odbc_exec($db, "SELECT id, name FROM table");

$num_records_fetched  = 0;
$num_records_to_fetch = 2;

while ($row = odbc_fetch_array($result)) {
   $num_records_fetched++;
   echo "Row {$num_records_fetched}:";
   foreach ($row as $key => $value) {
      echo " {$key} => {$value}";
   }
   if ($num_records_fetched >= $num_records_to_fetch) {
      break;
   }
}


Expected result:
----------------
I'd expect to see:

row 1: id => 0001 name => foo
row 2: id => 0002 name => bar



Actual result:
--------------
I get an "access violation".


If I change "num_records_to_fetch" to 1, it no longer violates access, but I see this instead:

row 1: 0001 => 0001 foo => foo



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-07-22 14:54 UTC] wez@php.net
I know this is side-stepping the issue slightly, but would you mind testing the PDO?

For a bit more info:
http://netevil.org/node.php?uuid=bf0a58d7-68ab-49d0-9a29-f5ec97c5dfde

You'll need:
http://snaps.php.net/win32/PECL_5_0/php_pdo.dll
http://snaps.php.net/win32/PECL_5_0/php_pdo_odbc.dll

Please reply directly to me (wez@php.net) with feedback on PDO.

 [2005-01-26 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".
 [2007-01-12 21:04 UTC] phil at pheelay dot com
I'm encountering this same issue using NexusDB and the ODBC driver in PHP 5.2.0.

* The columns returned by odbc_fetch_array() are not indexed by their column names, but by the values.
For Example:
"select Code, Designation FROM C_ARTICLE", I get:
Array
(
    [120105003] => 120105003
    [CacheCoeur TS] => CacheCoeur TS
)

* "SELECT * ...." crashes the (Apache 2.0.59) webserver.
"Parent: child process exited with status 3221225477 -- Restarting." from Apache logs)

However, I can use odbc_fetch_array() multiple times which OP was unable to do.


I tried using PDO and get the following for any query:

Warning: PDO::query() [function.PDO-query]: SQLSTATE[HYC96]: <<Unknown error>>: -1 Access violation at address 0589B12F in module 'nxOdbcDriverV2.dll'. Write of address 00000000 (SQLDescribeCol[-1] at ext\pdo_odbc\odbc_stmt.c:394)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 16:01:28 2024 UTC