|
Hi There, I am having some issues writing a UTF-8 (unicode) field from an external Java program to an AS/400 database. The Java class resides on a Unix Sun Server but it connects to an AS/400 and updates DB2/400 files via RPGLE stored procedures. 1. The field is defined on the AS/400 in the database (via QDDSSRC) as follows: WINKNM 20A TEXT('Nickname') CCSID(1208) VARLEN 2. The field is defined in the RPGLE Stored Procedure that updates the AS/400 database file in #1 as follows: D Nickname S LIKE(WINKNM) 3. The field is defined in the AS/400 RPGLE Stored Procedure definition as an input parameter: IN Nickname VARCHAR ( 20) CCSID 1208 4. The Java program calls the stored procedure passing it a unicode character string (this is where I think it is messing up the unicode value). Here is a snippet of the Java code doing the stored procedure call: // unicode test string with the up and down arrow symbols String originalString = "\u2192\u2193"; String finalString = ""; try { // Convert string to UTF-8 in java byte[] utf8Bytes = originalString.getBytes("UTF8"); // Create a UTF-8 string to send to AS/400 database finalString = new String(utf8Bytes, "UTF8"); CallableStatement cs = null; ResultSet rs = null; try { cs = conn.prepareCall(programUpdateDSNickname); cs.setString(1, finalString); rs = cs.executeQuery(); while (rs.next()) { successFlag = rs.getBoolean(1); } } catch (SQLException se) { throw new CSMException(se.getMessage()); } ..... My problem is that somewhere along the line the unicode field is not being passed into the AS/400 database as the proper unicode equivalent. Does it have something to do with the cs.setString that I am attempting to do? If anyone has been able to successfully update an AS/400 unicode ccsid(1208) field from a Java program, it would be great to know how you did it. Thanks very much! __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.