Bryan Pendleton wrote: > As an experiment, I tried commenting out the truncation > logic in DRDAConnThread.buildSqlerrmc(), and instead I > set maxlen to -1. > > Sure enough, the entire lock table string in the exception's > message text gets properly written to the SQLCAXGRP, and > by stepping through the code on the client side I can see > that the client successfully receives the entire message > text in the sqlerrmc field of the SQLCAXGRP there. > > However, the message text *still* does not appear on the > client side properly! > > I believe this is because the client's implementation of > SqlException.getMessage() calls Sqlca.getMessage(), which > is implemented as a call to SYSIBM.SQLCAMESSAGE. > > I Googled around for a while and came across > http://issues.apache.org/jira/browse/DERBY-285, which seems to > be touching the same areas of the code as I'm exploring, but > I kind of hit a dead end at that point. > > How do I go about learning more about SYSIBM.SQLCAMESSAGE?
Short answer without doing a lot of research but hopefully enough to send you in the right direction. The way the error messages work is that when the SQLCARD is returned to the client it returns the SQLSTATE and the parameter values for the message. Then the stored procedure SYSIBM.SQLCAMESSAGE is called to translate that into the actual localized error message returned to the client. The stored procedure lives in org.apache.derby.catalog.SystemStoredProcedures. I do know for sure that changing it would require upgrade changes. I seem to remember at one time looking at changing it to allow a bigger error message and hit some sort of problem (maybe compatiblity with older clients?) it is all fuzzy now.. One other issue for the sqlerrmc value in SQLCAXGRP is that we deviate from the DRDA spec here and allow greater than 70 characters for JCC and Client. For ODBC we send only 70 per the spec. An unfortunate a) limitation of the spec b) early violation of the spec that we have had to keep. Kathey
