JDBC Type 4 Driver Programmer's Reference for SQL/MX Release 3.1 (H06.23+, J06.12+)

exception or warning is thrown.
If the
translationVerification property’s value is TRUE and the driver cannot translate all or part of an SQL statement, the driver throws an
SQLException with the following text:
Translation of parameter to {0} failed. Cause: {1}
where {0} is replaced with the target character set and {1} is replaced with the cause of the translation failure.
For more information, see the
translationVerification Property.
Trimming Padding for Fixed-Length Character Columns
Sometimes retrieved values are longer than inserted values for fixed-length character columns that use the KANJI character set or KSC5601
character set in SQL/MP tables. This subsection describes:
How to reinsert a row that has fixed-length character items.
How padding causes the discrepancy in length.
Under most circumstances (for example, when the default Kanji=SJIS property key-value is set), the padding characters can be inserted and
selected from the database without error.
This is an advanced topic on character-set manipulation on SQL/MP tables.
How to Reinsert a Row that Has Fixed-Length Character Items
Note: The length of a retrieved string might not be correct if the associated column is double-byte and fixed length in
SQL/MP tables (for example KANJI and KSC5601). The number of padding characters might be more than
expected.
To avoid this length problem, ensure that the program trims any trailing white spaces before reinserting such a row before calling the
setString() method.
How the Padding Character Causes the Discrepancy in Length
SQL/MP tables containing fixed-length CHAR columns use an ASCII space character (0x20) as a padding character. Double-byte character
columns (KANJI and KSC5601) use two ASCII space characters (0x2020) as a padding character. UCS2 uses a single UCS2 space (0x0020)
as a padding character.
The 0x2020 character is not a legal character in the Kanji character set, but 0x2020 does represent two legal characters (two spaces) in the
SJIS character set. Under most circumstances the padding characters can be inserted and selected from the database without error (for
example, when the default
Kanji=SJIS property key-value is set).
For example, the pseudo code for an insertion into a table that has a column defined as
CHAR(6) character set KANJI, has the following
behavior:
byte b1 = new byte[4];
b1[0] = 0x83; \___ Katakana letter A
b1[1] = 0x41; /
b1[2] = 0x83; \___ Katakana letter small i
b1[3] = 0x42; /
String k1 = new String(b1, “SJIS”);
Internally, the JVM stores k1 as UCS2 in 4 octets (bytes). The UCS2 encoding would be:
0x30 0xA2 0x30 0xA3
An SQL insert statement is prepared:
pStmt = conn.PrearedStatement(“insert into t1 values (?)”);
The statements parameter is set to the string:
pStmt.setString(1, k1);
Internally, the Type 4 driver creates an array of bytes by using the following pseudo code:
byte inB = k1.getBytes(“SJIS”);
int colLen = 12; // i.e. the length of the column (6) times the max length of each character (2)
int padLen = colLen – inB.length; // inB.length = 4 (2 characters times 2 bytes per character)
inB = inB + 0x20 for padLen bytes;
The resulting insert has the following hexadecimal pattern:
0x83 0x42 0x83 0x42 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
A problem can occur when selecting the inserted row. If you were to select the same row as inserted, and call the getString() method, the
resulting string would not match the original string. For example:
rs = pStmt.executeQuery(“Select c1 from t1”);
rs.getString(1);
Internally, the Type 4 driver creates a string using the following pseudo code:
byte[] outB1 = getColumn1(); //