Bug #13783 Updated: odbc_fetch_into different issue

ID: 13783 User updated by: Grant.Walters@walters.co.nz Reported By: Grant.Walters@walters.co.nz Status: Analyzed Bug Type: ODBC related Operating System: SCO Openserver 5.0.5 & RH Lnux 7 PHP Version: 4.0.6 Old Assigned To: ahill Assigned To: New Comment: A correction to my previous information: The piece I commented out was in the php_opdbc.h file and was a reference to iodbc.h. This file is not present in the Openlink V4.1 ODBCSDK. I am unable to determine exactly which version of the SDK is being used as the Openlink ODBCSDK files have no version numbers anywhere. I have just finished testing against the SDK I downloaded with Openlink 3.2 bits. The odbc_fetch_into($results,$pos,$row) code works with both odbc_do and odbc_prepare statements, so it must be something to do with the new 4.1 SDK. Previous Comments: ------------------------------------------------------------------------ [2001-10-23 22:45:46] Grant.Walters@walters.co.nz Sorry about the last post. It is a different issue that I haven't raised yet. Can someone remove it. ------------------------------------------------------------------------ [2001-10-23 22:43:01] Grant.Walters@walters.co.nz A correction to my previous information: The piece I commented out was in the php_opdbc.h file and was a reference to iodbc.h. This file is not present in the V4 ODBCSDK. I am unable to determine exactly which version of the SDK is being used as the Openlink ODBCSDK files have no version numbers anywhere. However.... I have gone back to what I had with the Openlink 3.2 drivers (and put back the iodbc.h line). The same thing happens regarding the sql query containing a ('). However.... The Openlink team suggested a series of changes including using odbc_prepare. Using 3.2 and 4.1 the following works. $sql="SELECT ID,Category,description FROM card_type WHERE description=?"; $results = odbc_prepare($conn,$sql); $parms=array("PEPPERELL'S"); odbc_execute($results,$parms); if ($results) { while (odbc_fetch_into($results,$row)) { echo $row[0]." ".$row[1]." ".$row[2]."<BR>"; } } I still think it has to be a bug with on the PHP side to do with how PHP parses the $sql contents, that is resulting in a syntax error in the SQL statement passed to Openlink. According to the Microsoft ODBC SDK, error 37000 is remapped to 42000 which says: 42000: *StatementText contained an SQL statement that was not preparable or contained a syntax error. The user did not have permission to execute the SQL statement contained in *StatementText. This is definitely not a permission issue. Openlink alse mentioned changes to disable the use of DYNAMIC_CURSOR. As I currently can make the queries I need (so far), I will carry on with what I have. ------------------------------------------------------------------------ [2001-10-23 10:10:12] ahill@php.net The current SDK version is 3.0.5 and isql.h is included in it. Please get the SDK from either www.openlinksw.com or www.iodbc.org and recompile without commenting out the references. Best regards, Andrew Hill OpenLink Software ------------------------------------------------------------------------ [2001-10-22 20:59:00] Grant.Walters@walters.co.nz No errors at all, just returns an empty recordset. One probably important note. When I compiled PHP 4.0.6 I had to remove the reference to isql.h? in the php_odbc source program as it wasn't in the Openlink SDK for Openlink 4.1. Everything seems to work except the selected record stuff which hasn't ever worked for me using PHP 4 against Openlink. I think I had it working under PHP 3.0.15 against Openlink 3.2, but we have moved on since then. ------------------------------------------------------------------------ [2001-10-22 20:56:36] Grant.Walters@walters.co.nz Using odbc_fetch_into($id, $number, $result_array); SQLAllocHandle ( ... ) SQL_SUCCESS SQLSetStmtAttr ( ... ) SQL_SUCCESS SQLAllocHandle ( ... ) SQL_SUCCESS SQLDriverConnect ( ... ) SQL_SUCCESS SQLGetInfo ( ... ) SQL_SUCCESS SQLGetInfo ( ... ) SQL_SUCCESS SQLAllocHandle ( ... ) SQL_SUCCESS SQLGetStmtAttr ( ... ) SQL_SUCCESS SQLGetStmtAttr ( ... ) SQL_SUCCESS SQLGetStmtAttr ( ... ) SQL_SUCCESS SQLGetStmtAttr ( ... ) SQL_SUCCESS SQLGetInfo ( ... ) SQL_SUCCESS SQLSetStmtAttr ( ... ) SQL_SUCCESS SQLExecDirect ( ... ) SQL_SUCCESS SQLNumResultCols ( ... ) SQL_SUCCESS SQLNumResultCols ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLBindCol ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLBindCol ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLBindCol ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLBindCol ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLBindCol ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLBindCol ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLColAttribute ( ... ) SQL_SUCCESS SQLBindCol ( ... ) SQL_SUCCESS SQLExtendedFetch ( ... ) SQL_SUCCESS SQLExtendedFetch ( ... ) SQL_ERROR SQLFreeHandle ( ... ) SQL_SUCCESS SQLDisconnect ( ... ) SQL_SUCCESS SQLFreeHandle ( ... ) SQL_SUCCESS SQLFreeHandle ( ... ) SQL_SUCCESS ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=13783 Edit this bug report at http://bugs.php.net/?id=13783&edit=1