UTF8 character set uses CESU-8 code points, which are not compatible with the client character set AMERICAN_AMERICA.AL32UTF8 but are compatible with the client character set AMERICAN_AMERICA.WE8MSWIN1252.
Read here: http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm#_Toc110410550 http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14225/ch11charsetmig.htm#CEGCGEAF <http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm#_Toc110410550> I believe there is invalid data in the db that will have to be converted/cleaned up if you want to change the client localization settings and expect it to work. This means moving all the 8-bit characters (CESU-8, or whatever else there are) to the proper UTF-8 code point so that a client expecting that data can understand it. -- Axton The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. On Thu, Jan 28, 2010 at 12:15 PM, Shellman, David < dave.shell...@tycoelectronics.com> wrote: > ** > Axton, > > Here is what I got back from our DBA. > > > "The data in the database is in utf8 characterset. The database would not > allow it to be stored other than that. > > The application would have a failure on the storing of invalid characters > which would show up on the (application server). > > I can run the csscan though. > > The csscan is used when you want to convert your characterset and we do not > want to do that." > > Dave > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
