#38923 [Opn]: ODBC works through command line but not Apache
ID: 38923
User updated by: matthew dot berry at wolseley dot co dot uk
Reported By: matthew dot berry at wolseley dot co dot uk
Status: Open
Bug Type: ODBC related
Operating System: Unix
PHP Version: 5.1.6
New Comment:
Thought I should just mention that there is no delay in processing the
page through apache. The page is returned within a couple of seconds
(roughly the same length of time taken via cli), almost as if the
connection is dropped immediately (which is not the case as phpinfo
still shows one active connection in odbc at the end of the page). This
is a very irritating problem as we are so desperately close to resolving
this issue.
Previous Comments:
[2006-09-25 08:06:08] matthew dot berry at wolseley dot co dot uk
Settings for Apache are
Timeout 60
KeepAlive On
MaxKeepAliveRequests 200
KeepAliveTimeout 15
StartServers40
ThreadLimit 75
MinSpareThreads 32
MaxSpareThreads 64
MaxClients 300
ThreadsPerChild 75
MaxRequestsPerChild 1
Php.ini are:
max_execution_time = 30 ; Maximum execution time of each script, in
seconds
max_input_time = 60 ; Maximum amount of time each script may spend
parsing request data
memory_limit = 8M ; Maximum amount of memory a script may consume
(8MB)
As stated earlier, the command line returns back and displays row data
in under 2 seconds, but when running through the Apache server, the
code fails to execute. What would cause this difference?
[2006-09-22 15:57:49] [EMAIL PROTECTED]
The warning you're seeing (08S01) is telling you that something
happened with the connection and it was lost. Check your timeouts and
query length to ensure that neither of these is killing the connection.
[2006-09-22 10:52:00] matthew dot berry at wolseley dot co dot uk
Description:
We are using Unix, Apache version 2.0.54 and PHP 5.1.2 to connect to a
database (Northgate Reality) using the Unix ODBC protocol and the
Northgate Unix driver.
When we run the SQL statement shown below through ISQL on the web
server, the expected results are returned.
When we run the PHP page directly on the command line using the PHP
parser, we get the html generated correctly.
When going through Apache we get the following error:
Warning: odbc_do() [function.odbc-do]: SQL error: [Northgate][SNI]
Transport Error : Receive Failure, SQL state 08S01 in SQLExecDirect in
/sites/intranet/wuk/TermsReview/connecttest3.php on line 62
Which is a generic error message.
Part of the code used is shown below:
Reproduce code:
---
$rfp = odbc_connect($rdsn,$ruser,$rpwd);
if($rfp){
echo "Connected to ".$rdsn."";
$select = "SELECT ACCOUNT_NO, CUSTOMER_NAME FROM
GLOBAL_CUSTOMER_DETAILS WHERE ACCOUNT_NO = '7459C30'";
echo $select."";
$result = ODBC_DO($rfp,$select);
etc etc
Expected result:
The message is produced when it hits the ODBC_DO statement, the
connection to the database succeeds and has been traced.
I have tried several things such as using a persistant connection,
using odbc_prepare before it (which also fails).
When I include phpinfo at the end it shows that there is an active odbc
connection.
I realise that his could be a driver issue (although tracing has shown
otherwise thus far). But the fact that running the exact same page from
the command line works but doesn't through Apache means something ain't
quite right.
--
Edit this bug report at http://bugs.php.net/?id=38923&edit=1
#38923 [Fbk->Opn]: ODBC works through command line but not Apache
ID: 38923
User updated by: matthew dot berry at wolseley dot co dot uk
Reported By: matthew dot berry at wolseley dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: ODBC related
Operating System: Unix
PHP Version: 5.1.6
New Comment:
Settings for Apache are
Timeout 60
KeepAlive On
MaxKeepAliveRequests 200
KeepAliveTimeout 15
StartServers40
ThreadLimit 75
MinSpareThreads 32
MaxSpareThreads 64
MaxClients 300
ThreadsPerChild 75
MaxRequestsPerChild 1
Php.ini are:
max_execution_time = 30 ; Maximum execution time of each script, in
seconds
max_input_time = 60 ; Maximum amount of time each script may spend
parsing request data
memory_limit = 8M ; Maximum amount of memory a script may consume
(8MB)
As stated earlier, the command line returns back and displays row data
in under 2 seconds, but when running through the Apache server, the
code fails to execute. What would cause this difference?
Previous Comments:
[2006-09-22 15:57:49] [EMAIL PROTECTED]
The warning you're seeing (08S01) is telling you that something
happened with the connection and it was lost. Check your timeouts and
query length to ensure that neither of these is killing the connection.
[2006-09-22 10:52:00] matthew dot berry at wolseley dot co dot uk
Description:
We are using Unix, Apache version 2.0.54 and PHP 5.1.2 to connect to a
database (Northgate Reality) using the Unix ODBC protocol and the
Northgate Unix driver.
When we run the SQL statement shown below through ISQL on the web
server, the expected results are returned.
When we run the PHP page directly on the command line using the PHP
parser, we get the html generated correctly.
When going through Apache we get the following error:
Warning: odbc_do() [function.odbc-do]: SQL error: [Northgate][SNI]
Transport Error : Receive Failure, SQL state 08S01 in SQLExecDirect in
/sites/intranet/wuk/TermsReview/connecttest3.php on line 62
Which is a generic error message.
Part of the code used is shown below:
Reproduce code:
---
$rfp = odbc_connect($rdsn,$ruser,$rpwd);
if($rfp){
echo "Connected to ".$rdsn."";
$select = "SELECT ACCOUNT_NO, CUSTOMER_NAME FROM
GLOBAL_CUSTOMER_DETAILS WHERE ACCOUNT_NO = '7459C30'";
echo $select."";
$result = ODBC_DO($rfp,$select);
etc etc
Expected result:
The message is produced when it hits the ODBC_DO statement, the
connection to the database succeeds and has been traced.
I have tried several things such as using a persistant connection,
using odbc_prepare before it (which also fails).
When I include phpinfo at the end it shows that there is an active odbc
connection.
I realise that his could be a driver issue (although tracing has shown
otherwise thus far). But the fact that running the exact same page from
the command line works but doesn't through Apache means something ain't
quite right.
--
Edit this bug report at http://bugs.php.net/?id=38923&edit=1
#38923 [NEW]: ODBC works through command line but not Apache
From: matthew dot berry at wolseley dot co dot uk
Operating system: Unix
PHP version: 5.1.6
PHP Bug Type: ODBC related
Bug description: ODBC works through command line but not Apache
Description:
We are using Unix, Apache version 2.0.54 and PHP 5.1.2 to connect to a
database (Northgate Reality) using the Unix ODBC protocol and the
Northgate Unix driver.
When we run the SQL statement shown below through ISQL on the web server,
the expected results are returned.
When we run the PHP page directly on the command line using the PHP
parser, we get the html generated correctly.
When going through Apache we get the following error:
Warning: odbc_do() [function.odbc-do]: SQL error: [Northgate][SNI]
Transport Error : Receive Failure, SQL state 08S01 in SQLExecDirect in
/sites/intranet/wuk/TermsReview/connecttest3.php on line 62
Which is a generic error message.
Part of the code used is shown below:
Reproduce code:
---
$rfp = odbc_connect($rdsn,$ruser,$rpwd);
if($rfp){
echo "Connected to ".$rdsn."";
$select = "SELECT ACCOUNT_NO, CUSTOMER_NAME FROM
GLOBAL_CUSTOMER_DETAILS WHERE ACCOUNT_NO = '7459C30'";
echo $select."";
$result = ODBC_DO($rfp,$select);
etc etc
Expected result:
The message is produced when it hits the ODBC_DO statement, the connection
to the database succeeds and has been traced.
I have tried several things such as using a persistant connection, using
odbc_prepare before it (which also fails).
When I include phpinfo at the end it shows that there is an active odbc
connection.
I realise that his could be a driver issue (although tracing has shown
otherwise thus far). But the fact that running the exact same page from
the command line works but doesn't through Apache means something ain't
quite right.
--
Edit bug report at http://bugs.php.net/?id=38923&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38923&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38923&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38923&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38923&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38923&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38923&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38923&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38923&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38923&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38923&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38923&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38923&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38923&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38923&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38923&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38923&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38923&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38923&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38923&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38923&r=mysqlcfg
