DB2 SQLCODE=-805, SQLSTATE=51002, SQLERRMC=NULLID.SYSLH203 0X5359534C564C3031

Question

I am getting this error below :

 com.ibm.db2.jcc.am.SqlException: DB2 SQL Error: SQLCODE=-805, SQLSTATE=51002, SQLERRMC=NULLID.SYSLH203 0X5359534C564C3031, DRIVER=3.58.81 

in the execution of application after a certain point of time. Not got any fruitful answer on the web.

Fiddlewood

Which version of DB2? What reason codes/other information are you getting? Did the listed resolution steps not work? -805usually indicates a package is missing; I've never heard of it cropping up during runtime, though (it usually prevents statements from being run right off). – Frerichs

we are using DB2 9.7 version. We are still not able to figure out the real cause. As this error is not regular. – Fiddlewood

Answer 1

I got this error when I was using prepareStatement in loop without closing it inside loop. Closing the preparedStatement within loop resolved the issue.

Wilde

Were you creating new PreparedStatements inside the loop by any chance ? If that was the case, maybe creating the PreparedStatement just once before the loop would have been a more efficient solution than closing it on each loop cycle. – Air

Answer 2

This is an indication that the application is running out of resources; possibly due to not closing connections (too many prepared statements or other such poor programming).

If you have access to the application, consider making sure the connections are released when not needed. Otherwise, you need to reduce the constraints on the application. Try increasing APPLHEAPSZ and MAXAPPLS but really you should investigate this from the application side.

Mile

Answer 3

Hi I came into the same problem and I can confirm that the problem was a list of operations made with the same PreparedStatement, which was never closed.
After closing it the error did not occur anymore.

Egin

A PreparedStatement is made to be open once, reused as many times as needed (be it 1 000 000 times) and closed once. Perhaps you weren't commiting the data often enough, but I don't see how reusing the same PreparedStatement object would yield that error ... – Air