screwy problem sql is not working?

[chrisbirk]

Here is the scenerio, two i's both running V7R1, both have on basically same zend software (I think only latest hotfix is not on). Machine 1 runs php application internally, Machine 2 runs it externally for our call center.

The problem we are having is that machine2 at times, the selects, etc. do not work. They return nothing. No errors seem to show up anywhere. Just null return. To do initial login, I go and take ibmi user/pw and do a connect and if I can then I know that the user is good. That always work. But in the code (which is identical except for the url's) we do pconnects as alan sieden at common convinced me how much faster they are. But nothing will happen.

What it appears like is happening is that we are getting connections that are evidently dieing on the i side of things???? and nothing happens. Example, last friday, I set up the users for the call center, and I checked them out and they would return the various information. Last night when call center tried it, nothing happens (I mean php is running, no results on anything is showing). I could not get it to work myself, I restarted zend server etc. and still nothing. I even think when I saw this a month ago I did a re-ipl (but I have slept so I could be wrong about that), but then all of a sudden it started to work.

Ideas???? (the code is identical and it just acts like even though we are connected nothing is being returned but NO error)?????

[aseiden]

Hi, Chris,

1. Check db2_stmt_error() and db2_stmt_errormsg(). Perhaps there is an error or warning there.
2. If you are using the toolkit and have a toolkit connection, check what comes back from $conn->getJobAttributes() to see what job you're using, library list, etc. Then you can look at the actual job via WRKJOB and look for problems.
3. I suggest logging the actual SQL that you are using. Perhaps some of the WHERE parameters are wrong due to an earlier error.

Also, even though I advise pconnect for speed: perhaps an error, bad libl, etc, is creeping into these shared jobs. If you are encountering a serious problem in production, change to regular db2_connect and see if the problem goes away. db2_connect lets each request have a fresh job, which brings overhead, but ensures that it will be "clean" of any problems created by others.

Alan