ID: 13783
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
