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.

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? 

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

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);

}

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

did you encounter this bug in later (preferrably 4.0.4) versions of PHP?

After changing the server OS to Windows 2000 SP1, using IIS 5.0 instead of Apache and PHP 4.0.3, the error did not occur any more.
However, we did not examine exactly what did solve the problem, the new OS, the IIS or the new PHP version.

When I have time, I will examine this further, at the moment, I am just glad to have a working solution.

Thanks!

Hi, again!

I have examined the problem further, and the solution is:

When using the CGI-mode of PHP, the TNSNAMES.ORA and SQLNET.ORA must NOT contain DOS/WINDOWS CR/LF, but only UNIX LFs.

In the ISAPI mode, this does not matter at all.

Frank