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