|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #25505 SQLExtendedFetch() vs SQLFetch()
Submitted: 2003-09-11 21:32 UTC Modified: 2003-09-22 06:46 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: michaelc at mikeit dot com dot au Assigned:
Status: No Feedback Package: ODBC related
PHP Version: 4.3.3 OS: Win32
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2003-09-11 21:32 UTC] michaelc at mikeit dot com dot au
Trying to write a php gtk frontend to a MYOB (manage your own business) database.

They provide a suitably crippled ODBC driver, which via Perl, I can determine that it supports only SQLFetch, rather than PHP's default of SQLExtendedFetch.

I know how to recompile on linux to change PHP's behavious, but how would I do this on Win32 ? Is there an .ini flag, or SQL command option I can set to work around this ?

Is there any chance of getting PHP to implement a flag as to what SQL fetch command it uses for ODBC ?

Not that that the exec function actually works, and returns data, and the program works correctly up until I terminate where I get the error message on exit.

Reproduce code:

if (!class_exists('gtk')) {
	if (strtoupper(substr(PHP_OS, 0, 3)) == 'WIN')

function delete_event()
	return false;

$connectionstring = odbc_connect("MYOB","michaelc","") or die(odbc_error());

$query = "SELECT * FROM Cards";
$queryexe = odbc_do($connectionstring, $query);


$window = &new GtkWindow();
$window->connect_object('destroy', array('gtk', 'main_quit'));
$window->connect('delete-event', 'delete_event');

$window->set_title('PHP Rules!');
$window->set_usize(150, 200);

/* Run the main loop. */


Actual result:
The instruction at "0x01c7e090" referenced memory at "0x01ca5170". The memory could not be "read".

On exit of program, program runs successful until this point.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-09-11 22:08 UTC] michaelc at mikeit dot com dot au
Ran GDB under cygwin for the script:

(gdb) run odbc_test.php
Starting program: /cygdrive/c/php4/php.exe odbc_test.php
---Type <return> to continue, or q <return> to quit---

Program received signal SIGSEGV, Segmentation fault.
0x01c7e090 in MYOBSp32!_AppDebugInfoEnable@4 ()
 [2003-09-11 22:23 UTC]
What would '(gdb) bt' (bt, as in backtrace) output?
That small part of it looks more like the MYOB crashes rather than PHP..

 [2003-09-11 23:30 UTC]
Following ODBC spec's ExtendedFetch is required for API conformance Level2, the minimum PHP supports (I believe).  You should probably contact the MYOB people and inform them to use a fully compliant ODBC driver, such as the Microsoft one.

That being said you can also just set HAVE_SQL_EXTENDED_FETCH to 0 and life should be golden for you to bypass this.
 [2003-09-16 00:39 UTC] michaelc at mikeit dot com dot au
Will the windows version heed windows system variables ? 
Will try the next time I boot across to win32.
 [2003-09-16 08:39 UTC]
Not that I know of.  It will require a recompile to insert this change.
 [2003-09-22 06:46 UTC]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

 [2005-02-10 00:05 UTC] moreinfo at potentialtech dot com

The problem I am seeing is that SQLExtendedFetch is Deprecated.  It has been replaced by SQLFetchScroll.  Only newer ODBC drivers which are not backwards compatible will fail.

The unified ODBC driver is using this deprecated ODBC Standard by default in the win32 version of php.  Workarounds exist, but this problem may become more common with time.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Fri Dec 08 04:01:27 2023 UTC