db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: Question about message token separators
Date Fri, 20 May 2005 17:31:09 GMT
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
>
>
>
>
>
>
>  
>


Mime
View raw message