db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Question about message token separators
Date Thu, 19 May 2005 21:41:09 GMT
I am looking at Derby-285

Network Client should not print non-ascii token separators in message
when it cannot connect to the server to retrieve the error message
These characters break Jira Export if a Network Client trace is put into

Currently the message tokens get sent by the server to the client in the
The client then calls a stored procedure SYSIBM.SQLCAMESSAGE  with the
SQLERRMSG_m value as a parameter  to get the full localized message.  A
non ascii separator is used  as a token separator and used by the stored
procedure to separate the tokens.

In the server (DRDAConnThread) we have these separators.
                byte[] sep = {20};    // use it as separator of sqlerrmc
                byte[] errSep = {20, 20, 20};  // mark between exceptions
                String separator = new String(";");
                String errSeparator = new String(errSep);

 The client normally just sends the full string back to the server, but
does have code to split up the tokens if it can't retrieve the message.
This code expects a byte value of -1 as a separator.

 // non-delimiter - continue to write into buffer
                if (tokenBytes[index] != -1)  // -1 is the delimiter '\xFF'

Short term options include:

    1) Send an ascii separator of some sort.  (Is there some safe value
that would not be in the messages?)
    2)  Change  the client to expect what the server is sending.
    3)  Change  the server to send what the client is expecting.

I'm leaning toward 2 so as not to impose any risk for backward
compatibility or odbc or whatever.  On the other hand I always thought
those separator values in the server were a bit weird.  Does anyone have
any thoughts on this?


View raw message