I think option 2 is good. Derby client shouldn't be using non-Ascii
characters in the message being returned.
Satheesh
Kathey Marsden wrote:
>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
> Jira.
>
>Currently the message tokens get sent by the server to the client in the
>SQLERRMSG_m field of the SQLXCAXGRP.
>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
>tokens
> 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.
>
>org.apache.derby.client.am.SQLca.java:
> // 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?
>
>
>Kathey
>
>
>
>
>
>
>
>
