|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #14254 SQLERROR -439
Submitted: 2001-11-27 12:36 UTC Modified: 2002-05-25 13:15 UTC
From: cedric dot boudin at iconmedialab dot com Assigned:
Status: Closed Package: Informix related
PHP Version: 4.0.6 OS: Solaris 8
Private report: No CVE-ID: None
 [2001-11-27 12:36 UTC] cedric dot boudin at iconmedialab dot com
Similarly to Bugs 13459 and 8267 we do get error 439.

on php 3.0.18 and 4.0.6

we do have support from ifx.

they are prepared to help us

here qote from ifx support 


I have received this case and I have looked through the case history. The

situation appears to be as follows.

Your network traffic has increased and that in turn brought about more

timeout situations where an ESQL/C callback was used by your application (or

by PHP). The -439 error indicates that unauthorized calls are included in

that callback function.

There are two ways to avoid getting the errors.

	1. Tweak the system to increase performance to the point where the

timeouts do not occur.

	2. Fix the callback function code.

Since you have indicated that you will not attempt number 1 we are left with

number 2. Number 2 is the responsibility of the person that wrote the

callback function, be that you or PHP. 

The only way that Informix can fix the problem is if the -439 is being given

in error. At this time there is no indication that the -439 error is not

correct but it is still a possibility. Unfortunately we cannot know whether

or not the -439 error is erroneous or not until we know exactly how the

callback function is being set up. So the next thing that must happen is

that I get a small test case showing setting up a correct callback function

that fails with this error. 

If you are writing the callback functions then we need to get PHP out of the

picture and you need to provide me a very small ESQL/C test case that gives

the same error.

If the callback functions are contained in PHP then the only other option is

to pursue an answer through Apache tech support and let them contact me when

and if they find that the -439 is not correct. In that case they will be

providing the test case. If PHP cannot be removed from the picture then you

need to open a case with Apache as soon as possible. Given the nature of

Apache this might not be a viable option and you may instead want to look at

the PHP source yourself.

-- end quote

--- begin quote

Both the -439 and the -25588 errors are occuring because of timeouts. Odds

are that they are simply different symptoms of the same underlying problem

and which error you get depends on timing of internal events.

If you want to focus on performance tuning I can pass the case back to an

engines engineer. This will only be brushing the problem under the carpet,

however. If your application is not doing callbacks correctly then it will

give this error any time that activity gets too high.

Does your application provide the callback function or is that all built

into PHP?

-- end quote

so now we have the chance to get rid of this annoying bug. I cnnot possibly plunge into the phpsourcecode to get the info the guy from ifx needs.

If your are interested to get this thing sorted out this is the chance


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2001-11-27 12:57 UTC]
Can you please add a short PHP script with which you can
reproduce this ? Also, please try PHP 4.1.0 (to be released
very soon now) as it has some improvements to the threading
which might actually fix this problem.

(it was mentioned as one possibility in that mail you 
pointed to in the archives)

I don't have informix installed or any knowledge how to
set it up either so you need to help us in this.

And I don't have much time to spend on this either so please
be patient.


 [2001-11-28 07:26 UTC] cedric dot boudin at iconmedialab dot com
a short script would not reproduce the conditions for recreating the failure.

It happens when we have a lot of load and this with big scripts using lots of memory and sometimes timing out.
If the timeout comes from the db connection being lost or vice versa is hard to say

If we could isolate where in the php ifx interface callback functions are used we would be a step further in solving this.

 [2002-05-25 09:13 UTC] alan dot frostick at iconmedialab dot com
Referring to Bug #14254.

I can give some background clues which might help in resolving the
intermittent SQLCODE=-439 error faster.
I support the php scripts for the same server which Cedric supports. We
have noted that our client has increased their volume of data and
traffic to the site dramatically since their intranet's inception over a
year ago.

They're still using php3 (we're trying to convince them to pay us to
convert their scripts to php4, but presently can't guarantee this would
resolve the problem since it's still being reported by others using

The effect seen is a refusal to connect to informix, caused by a peak in
traffic. It's not something which is easily duplicated in a test
environment, and is a mercurial problem in that as soon as it occurs, it
often dissappears again as suddenly. We've seen it occur regularly for
up to 40 minutes and then go away for several days.

Recently the complaint has been that some scripts simply return an empty
page. On investigation this week I discovered these scripts were
building massive arrays while remaining connected to informix, and
apparently exceeding maximum script memory. It happens within 4-5
seconds so can't be the result of a timeout.

I suspect this is giving rise to accumulated garbage somewhere or
leaving locks in the database and has a serious effect on subsequent
attempts to connect to informix, which (sometimes) return SQLCODE=-439
error codes from ifx_connect().

We've tried using both ifx_connect and ifx_pconnect for the scripts, but
this makes no apparent difference, just as increasing connection limits
has failed to.

I've since optimised some of the offending scripts and this seems to
alleviate the problem in the short-term, but a huge overhaul of the
methods used is overdue but cannot be done so quickly, given the
complexity of the intranet.

We'd like a resolution of the problem as soon as possible, even with
scripts timing out or exceeding memory limits. I see you've recently
improved the memory threading, and wonder if this could finally crack
this long-standing problem?
Alan Frostick
 [2002-05-25 13:15 UTC]
Your problem seems to be a pure performance issue. 
Unfortunately these kinds of problems present themselves in 
a non-deterministic fashion, which makes the symptoms hard 
or impossible to debug. The cure, however, seems clear: 
upgrade to PHP 4.2, upgrade the hardware, install Zend 
Optimizer, buy Zend Cache -- anything to match your server 
resources with the increased load on your system. 

Based on your description of the scripts used, PHP 4 alone 
should bring a huge performance increase. Your client's 
possible unwillingness to pay for upgrades is quite simply 
*their problem*. Hang in there, iconites ;-)

 [2002-07-06 17:35 UTC] pschmidt at naxs dot net
Well, I see this problem every time I run my scripts.  We are running:

PHP 4.2.1
Apache 1.3.24
ESQL/C Version 9.51

Some of the Informix tables are large.

Since I am seeing this consistently, I would really like to see a fix to this problem.  My scripts are somewhat complicated.  But I can reproduce the problem with a simple script.  It contains:


// create connection
$connection = ifx_connect("<deleted>", "<deleted>", "<deleted")
        or die("Couldn't create connection.");

// create SQL statement
$sql = "SELECT f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13, f14 FROM T1 where f1 < 500";

// execute SQL query and get result
$sql_result = ifx_query($sql,$connection)
        or die("Couldn't execute query");

// format result in HTML table

// free resources and close connection


To reproduce this, I hit the refresh button on the browser before the page had downloaded.

I tried switching it to pconnect and still got SQLCODE=-439 failures.  Although the table is big, I think the load was light (I tried this on a Saturday afternoon.) 

Anyone that has questions, feel free to send them to me at

Best Regards,
Paul Schmidt
Action Web Creations
 [2003-02-23 20:32 UTC] neil dot wilkinson at transport dot nsw dot gov dot au
This problem still exists and does indeed occur most often when the database is busy.

However, there will always be situations where the database is busy, so increasing performance will only help in some situations.

The problem appears to be to do with how PHP responds to the callback functions.  I believe that the apache and native ESQL libraries are bug free in this respect because embedded perl, etc (hitting the same database from the same machine using the same ESQL libraries) never has this problem.

Is there anyone out there that understands the PHP IFX source code and could fix the callback functionality.  Failing that I could have a go if given some assistance.

FYI, the server specifics are:

Solaris 2.6
Apache 1.3.27
PHP 4.2.3
ESQL 7.24.UC6
Informix 7.30.UC8

Please do not close this bug unless the problem has been solved.  Several instances around this bug have been closed by the solution "upgrade hardware" where there is clearly still an error to be fixed.


Neil Wilkinson
 [2003-07-10 20:04 UTC] shai at shai dot org
I am using AIX4.3.3
Apache 1.3.22
PHP 4.3.1
Infrmx 7.3.1
Same problem, I am using the RS6000-M80 and I can reproduce the problem
when I am the only person on the machine with small queries. I suspect
that this maybe an apache related issue. I notices that my apache has
spawned off 20+ children. So I started messing with the persistant
connection and timeout options, seems to have made the problem go away
for now. Even with multiple hits, apache doesn't seems to be spawning
more than 12 helpers.

Any comments from anyone?
 [2003-08-08 13:55 UTC] klightse at water dot ca dot gov
Well, we came up with a hack to work around this miserable bug.  You can see our environment listed in the posting we made above.  The following is our assessment of the problem and the work around solution:

ifx_connect call (from Informix CSDK) fails on repeated queries. The problem seems to be that it believes that the returned connection ID is already in use!

The informix error follows:

-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.

Found reports of a PHP bug that seems related (#14254).
Bug goes back years, no fix reported.  Just "make system faster".

I found anohter related(?) bug (#18534 ifx_close() leaves open session)

Docs on ifx_connect show the following:

"In case a second call is made to ifx_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned."

Theory is that ifx_close doesn't immediately close the connection. Since the parameters in ifx_connect are always the same (user, passwd and database), the next ifx_connect() tries to use the existing connection, and sometimes fails (busy, in process of closing, ???) 

Our fix:  Try using "rotating users" - we set up 10 "bdtdb" users (bdtdb0-9), all with same uid/passwd on Solaris system.  Use different one for each connect, the chance of colliding with an open/bad connections drops a lot (doesn't go awasy completely).

Here's our code:  

                  // This is a hack to work around
                  // the bug 439 (see Informix docs                              
                  // - finderr 439) that relates to
                  // PHP concurrency problems with
                  // Informix.
                  // In essence, we are recycling
                  // usernames so that we can convince
                  // Informix to issue a new resource id
                  // for our connection, thus preventing
                  // collisions.  Note that collisions
                  // could still occur, but it would be
                  // much less likely.  To make it even
                  // less likely, use more user names.
                  // This is the best we can do, 
                  // since no one here has the
                  // time to debug the PHP/Informix modules.

       function getDBUserName() {

          global $HTTP_SESSION_VARS;
          $NUM_USERS = 9;

          $user_index = $HTTP_SESSION_VARS['user_index'];

                                 // First time in
          if (!$user_index && $user_index != 0) {    

                        // $user_index = rand (0,$NUM_USERS);
                        // Random # between 0 and numusers
                        // This doesn't work even if it is
                        // seeded.  Always starts on 
                        // same number.  Go figure.

             $user_index = 0;
          else {

             $user_index = $user_index + 1;

             if ($user_index > $NUM_USERS)  $user_index = 0;


          $HTTP_SESSION_VARS['user_index'] = $user_index;

          return ("bdtdb" . $user_index);


    //-----------------------  Defined Vars -------------

        $db_userid   = getDBUserName();
        $db_password = "fish911";
        $db_database = "www_bdat@ius_baydelta_tcp";

   // ----  Then use these in your connection to db.  
   //       We are definitely not using persistent
   //       connections.

Tested this hard - could not make it break, even with heavy load.  Prior to fix, even light loads would create error.
 [2003-09-16 10:46 UTC] shai dot silberman at wsgriffith dot com
I was able to resolve this problem by installing a newer informix client and recompiling PHP. I have not had a single 439 error since.
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Wed Jun 03 14:01:25 2020 UTC