× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




I also think that, unless you've got things set up really funny, you should not get an "sql statement overflowing the field." I'd expect a data truncation warning, which you can program to ignore, sort of getting automatic trimming.

To show more of my probably not understanding your question, if the database CCSID was set to a double byte code set, you should get double bytes even for LT 128 values. If you're instead slamming potentially double byte data into a single byte CCSID, it's all on you since it will look like garbage to anyone and anything else.

Joe Sam

Joe Sam Shirah - http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International? http://www.jguru.com/faq/I18N
Que Java400? http://www.jguru.com/faq/Java400

----- Original Message ----- From: "Joe Sam Shirah" <joe_sam@xxxxxxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400" <java400-l@xxxxxxxxxxxx>
Sent: Tuesday, June 24, 2008 3:18 PM
Subject: Re: Determine if a String will result in a double byte value in DB2/400?



Hi David,

Not sure I completely understand, and you may (possibly, don't have the time to double[unintended pun] check) get snagged by some non-US EBCDIC variant where Unicode is double byte but the code set isn't. But...

You should be able to take the Unicode string character by character and put it into a char variable, which is 16 bits. Check the numeric value of the char. If GT 127, then it's a double byte.

Does that help or did I completely miss your problem?

I also wonder how helpful persisting only half a string will be. You do know that the AS/400 now supports UTF-8, right? Of course, that may not be an option; don't know your app. HTH,


Joe Sam

Joe Sam Shirah - http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International? http://www.jguru.com/faq/I18N
Que Java400? http://www.jguru.com/faq/Java400

----- Original Message ----- From: "David Gibbs" <david@xxxxxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400" <java400-l@xxxxxxxxxxxx>
Sent: Tuesday, June 24, 2008 2:50 PM
Subject: Determine if a String will result in a double byte value in DB2/400?


Folks:

Does anyone know if there is a way, using JT400, to determine if the
value of a String will result in double byte data once stored in a
DB2/400 database column (assuming an appropriate CCSID, like 5026)?

I've got a situation where I could be handed variable length unicode
data in a String variable ... and I need to store the value in a fixed
length DB2 database field. Problem is, I need to trim the data to the
appropriate length before setting the value in the sql statement so it
doesn't overflow the field.

Thanks!

david

--
IBM System i - For when you can't afford to be out of business

--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.