PHP 4.0 Bug #5814 Updated: ODBC connection to Oracle fails

ID: 5814 Updated by: cynic Reported By: fsegtrop@estiem.org Old-Status: Open Status: Feedback Bug Type: ODBC related Assigned To: Comments: did you encounter this bug in later (preferrably 4.0.4) versions of PHP? Previous Comments: --------------------------------------------------------------------------- [2000-07-28 21:38:16] fsegtrop@estiem.org Just an addition: The same bug occurs using Windows98 and Apache Web Server. The connection to Oracle via ODBC works with php3 and other ODBC-clients and fails with php4, where TNS cannot resolve the Oracle alias. Regards, Frank --------------------------------------------------------------------------- [2000-07-28 16:09:21] fsegtrop@estiem.org This is the c function that works, and it shows no big difference to the odbc_sqlconnect function used by php4: void myodbcconnect() { int rc; SQLHANDLE henv,hdbc; SQLAllocEnv(&henv); SQLAllocConnect(henv, &hdbc); rc = SQLConnect(hdbc,(unsigned char*)dsn,strlen(dsn),(unsigned char*)uid,strlen(uid),(unsigned char*)pwd,strlen(pwd)); if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO) { MessageBox(hWnd,"","Fehler",IDOK); SQLFreeConnect(hdbc); } else MessageBox(hWnd,"OK","",IDOK); } --------------------------------------------------------------------------- [2000-07-28 14:06:42] fsegtrop@estiem.org No, both php3 and php4 run as CGI, and with the same user. Also, everyone has full access to the tnsnames.ora. I have configured Apache the way that scripts ending with .php4 are executed by php4 and scripts ending with .php3 by php3. A script, run as "test.php4" fails, the same run as "test.php3" succeeds. Everything runs as CGI, not as Apache module. I have written a small test-program with C, and there the connection using SQLConnect works, as well as with php3. Somehow, in php4 the same function call (SQLConnect) returns SQL_ERROR. In php3 and my test-program, SQLConnect finds the missing parameters DBQ and ASY from the ODBC-driver and can resolve the DBQ setting, in php4 it also finds the DBQ and ASY parameters, but cannot resolve the DBQ, though there is no obvious difference in the environment (same users, same machine, same browser). Anyhow, the php_odbc.c source does not show me any hint why this behaviour occurs, and it appears to be a different environment, but then the same occurs on different machines. Always, php3 works, php4 does not work, other ODBC-clients work. One idea is: in php3, the SQLConnect runs from the exe, in php4 from a dll (even in the CGI-version), and the TNS-resolution does not work there? That's the only difference I have found so far. If i Find more, I'll update this report. Best regards, Frank --------------------------------------------------------------------------- [2000-07-28 09:06:30] kara@php.net There must be something different in the environment between php3 and php4. The oracle error you're getting implies that the oracle libs aren't able to find tnsnames.ora. Maybe you are running php3 as cgi and php4 as ISAPI? Or do you have a different user executing the scripts? --------------------------------------------------------------------------- [2000-07-27 20:08:27] fsegtrop@estiem.org With PHP3, the following log file is created: php 134:11c ENTER SQLAllocEnv HENV * 0x00486a40 php 134:11c EXIT SQLAllocEnv with return code 0 (SQL_SUCCESS) HENV * 0x00486a40 ( 0x00aa1440) php 134:11c ENTER SQLAllocConnect HENV 0x00aa1440 HDBC * 0x00bc0490 php 134:11c EXIT SQLAllocConnect with return code 0 (SQL_SUCCESS) HENV 0x00aa1440 HDBC * 0x00bc0490 ( 0x00aa14e8) php 134:11c ENTER SQLSetConnectOption HDBC 0x00aa14e8 UWORD 110 <SQL_ODBC_CURSORS> UDWORD 0 php 134:11c EXIT SQLSetConnectOption with return code 0 (SQL_SUCCESS) HDBC 0x00aa14e8 UWORD 110 <SQL_ODBC_CURSORS> UDWORD 0 php 134:11c ENTER SQLConnectW HDBC 0x00aa14e8 WCHAR * 0x00aa15f0 [ -3] "WEP2000 0" SWORD -3 WCHAR * 0x1f4be068 [ -3] "****** 0" SWORD -3 WCHAR * 0x1f4be068 [ -3] "****** 0" SWORD -3 php 134:11c EXIT SQLConnectW with return code 0 (SQL_SUCCESS) HDBC 0x00aa14e8 WCHAR * 0x00aa15f0 [ -3] "WEP2000 0" SWORD -3 WCHAR * 0x1f4be068 [ -3] "****** 0" SWORD -3 WCHAR * 0x1f4be068 [ -3] "****** 0" SWORD -3 With PHP4, the log file is: php f1:121 ENTER SQLAllocEnv HENV * 0x00567f80 php f1:121 EXIT SQLAllocEnv with return code 0 (SQL_SUCCESS) HENV * 0x00567f80 ( 0x00a61440) php f1:121 ENTER SQLAllocConnect HENV 0x00a61440 HDBC * 0x00567f84 php f1:121 EXIT SQLAllocConnect with return code 0 (SQL_SUCCESS) HENV 0x00a61440 HDBC * 0x00567f84 ( 0x00a614e8) php f1:121 ENTER SQLSetConnectOption HDBC 0x00a614e8 UWORD 110 <SQL_ODBC_CURSORS> UDWORD 0 php f1:121 EXIT SQLSetConnectOption with return code 0 (SQL_SUCCESS) HDBC 0x00a614e8 UWORD 110 <SQL_ODBC_CURSORS> UDWORD 0 php f1:121 ENTER SQLConnectW HDBC 0x00a614e8 WCHAR * 0x00a615f0 [ -3] "WEP2000 0" SWORD -3 WCHAR * 0x1f4be068 [ -3] "****** 0" SWORD -3 WCHAR * 0x1f4be068 [ -3] "****** 0" SWORD -3 php f1:121 EXIT SQLConnectW with return code -1 (SQL_ERROR) HDBC 0x00a614e8 WCHAR * 0x00a615f0 [ -3] "WEP2000 0" SWORD -3 WCHAR * 0x1f4be068 [ -3] "****** 0" SWORD -3 WCHAR * 0x1f4be068 [ -3] "****** 0" SWORD -3 DIAG [S1000] [Oracle][ODBC Oracle Driver][Oracle OCI]ORA-12154: TNS:Der Servicename konnte nicht aufgelöst werden.. (12154) Again, both on the same machine, with exaclty the same ORACLE-installation. --------------------------------------------------------------------------- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=5814