Re: Informix returns SQLCODE=-439
| From: | Danny Heijl | Date: | Mon, 06 Mar 2000 19:15:02 +0000 |
| Subject: | Re: Informix returns SQLCODE=-439 | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-16469@lists.php.net to get a copy of this message | ||
-439 : Database server is currently processing an SQL task.
"You attempted to call an SQL routine or attempted to execute an SQL
statement within a signal handling function/routine or a callback
function/procedure. Use only the sqldone() and sqlbreak() library functions
inside your INFORMIX-ESQL/C callback function. Use only the ECO-SQD and
ECO-SQB library routines inside your ESQL/COBOL callback procedure. In
addition, if you want to unregister your callback function in
INFORMIX-ESQL/C, you can invoke the sqlbreakcallback() callback registration
function within your callback procedure. If you want to unregister your
callback procedure in ESQL/COBOL, you can invoke the ECO-SQBCB callback
registration routine within your callback procedure."
This seems to suggest that a signal handling routine tries to execute an
ESQL/C statement while another statement is still active.
There are no signal handling routines or ESQL/C callback functions inside
the PHP/Informix driver, it is all strictly synchronous, so I see no obvious
cause for your problem. Unless perhaps the user hits the stop button on his
browser, Apache fires the corresponding signal to modphp aborting the
request, with the Informix code still hanging in the connect code, and a
new request is processed with the connect code still not finished. I don't
know if such a scenario is possible, I am just guessing here.
I don't know if something similar could happen if a request hits the time
limit.
I certainly never experienced the problem, and it has not been reported
before.
BTW, is there a reason for not using persistent connections ? It should be a
lot faster.
Danny
---