ID: 5814
Updated by: cynic
Reported By: [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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
--
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]
