db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Lock table messages are truncated in Client/Server mode
Date Fri, 09 Dec 2005 04:07:49 GMT
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






Mime
View raw message