This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
We've got a very strange problem here. Our Oracle 8i database holds names in both UTF8 & Big5 (for chinese) together with a language column. We've written a JSP running on Websphere 4.0.1 which connects to the DB with a thin Oracle connection & retrieves the required name using the language of the logged on user (hope you're with me so far). If the language is Chinese it gets the converts the Big5 characters to UTF8 & then displays the result:-
When we run this on our Win2000 development App server it displays the correct Chinese characters but on our Solaris UAT system it doesn't. Both systems are connecting to the same Oracle DB.
After a bit of further investigation we've looked at the actual byte stream that is coming back from the DB :-
Whereas on dev we get :- -76 -70 -74 -74 -64 -12 -78 121 -74 -59 -88 -23 -80 -14 -86 -9 32 45 32 65 32 -86 -47 32 40 -78 -42 -83 112 -86 -47 -91 -9 41
Why is this happening? Why are -61 & -62 bytes appearing on one but not the other? It's not the DB as the data is coming from the same same source in both cases. It's not the code as it is identical & we're using the same classes12.zip in both cases. Both systems have the same Websphere jvm settings. All we can think of is some environment setting which is different.
Thanks in advance for any help you might be able to provide as it is driving us crazy.
I just wanted to verify if both application are pointing to same schema !!! or database schema is different but database server instance is same. [ November 02, 2004: Message edited by: Shailesh Chandra ]
just adding one more thing that In my environment I have to database server instance on one machine and their db parameters are different.
Joined: Sep 13, 2002
Thanks for the help.
Eventually got to the solution. We changed Websphere's jvm classpath so that the path to classes12.zip appeared first. We also removed other older versions of classes12.zip (some were renamed) from the lib folder, restarted the app server & all was happy again.