Обсуждение: Fwd: Re: unicode in 7.1
The was corrupted in the process of the upgrade. Is there some way to tell what the configuration options were when it was installed? I am assuming by API you mean how am I accessing Postgres? JDBC. Culley >X-Apparently-To: culleyharrelson@yahoo.com via web9605; 10 Sep 2001 >18:19:26 -0700 (PDT) >X-Track: 1: 40 >To: culleyharrelson@yahoo.com >Cc: pgsql-general@postgresql.org >Subject: Re: [GENERAL] unicode in 7.1 >X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 > =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= >Date: Tue, 11 Sep 2001 10:19:00 +0900 >From: Tatsuo Ishii <t-ishii@sra.co.jp> >X-Dispatcher: imput version 20000228(IM140) >Lines: 9 > > > my isp recently upgraded form postgreSQL 7.0 to 7.1. It went pretty well > > but I just discovered that non-english characters are now in the database > > as a question mark-- inserting non-english characters produces a ? as > > well. Any idea what has gone wrong and what we need to do to fix this? > >Hard to tell without knowing what the configuration option was and >what kind of API you are using... >-- >Tatsuo Ishii _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
> The was corrupted in the process of the upgrade. > > Is there some way to tell what the configuration options were when it was > installed? pg_config --configure > I am assuming by API you mean how am I accessing Postgres? JDBC. 7.1's JDBC driver has been slightly enhanced from 7.0 in the sense of encoding handling. Modify your Java applications to meet the new JDBC driver's requirements (do not ask me how, because I'm not a Java programmer) or stay with the old driver. -- Tatsuo Ishii
pg_config --configure produced: --enable-locale --with-CXX --prefix=/usr --with-perl --enable-multibyte --with-tcl --with-odbc --enable-syslog --with-python --with-openssl --with-krb5=/usr/kerberos --sysconfdir=/etc/pgsql --mandir=/usr/share/man --docdir=/usr/share/doc --includedir=/usr/include/pgsql --datadir=/usr/share/pgsql I did have some problems with JDBC not liking to open a resultset recursively but I just altered the code. Mostly I am concerned about all my non-english data-- I can't even recover if the database can't handle the data. Culley At 01:43 PM 9/11/01 +0900, you wrote: > > The was corrupted in the process of the upgrade. > > > > Is there some way to tell what the configuration options were when it was > > installed? > >pg_config --configure > > > I am assuming by API you mean how am I accessing Postgres? JDBC. > >7.1's JDBC driver has been slightly enhanced from 7.0 in the sense of >encoding handling. Modify your Java applications to meet the new JDBC >driver's requirements (do not ask me how, because I'm not a Java >programmer) or stay with the old driver. >-- >Tatsuo Ishii _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Culley, With out more details of your setup, I can't give you a complete answer. But check out the info at: http://lab.applinet.nl/postgresql-jdbc/#CharacterEncoding for a brief discussion of what I believe is your problem. There has also been a number of discussions on this on the pgsql-jdbc mail list. You might also want to check the mail archives. thanks, --Barry Culley Harrelson wrote: > The was corrupted in the process of the upgrade. > > Is there some way to tell what the configuration options were when it > was installed? I am assuming by API you mean how am I accessing > Postgres? JDBC. > > Culley > > >> X-Apparently-To: culleyharrelson@yahoo.com via web9605; 10 Sep 2001 >> 18:19:26 -0700 (PDT) >> X-Track: 1: 40 >> To: culleyharrelson@yahoo.com >> Cc: pgsql-general@postgresql.org >> Subject: Re: [GENERAL] unicode in 7.1 >> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 >> =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= >> Date: Tue, 11 Sep 2001 10:19:00 +0900 >> From: Tatsuo Ishii <t-ishii@sra.co.jp> >> X-Dispatcher: imput version 20000228(IM140) >> Lines: 9 >> >> > my isp recently upgraded form postgreSQL 7.0 to 7.1. It went pretty >> well >> > but I just discovered that non-english characters are now in the >> database >> > as a question mark-- inserting non-english characters produces a ? as >> > well. Any idea what has gone wrong and what we need to do to fix this? >> >> Hard to tell without knowing what the configuration option was and >> what kind of API you are using... >> -- >> Tatsuo Ishii > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >
Ack! I guess I am hitting this problem.... I had my database rebuilt to use UNICODE encoding. Data now appears correctly in pgsql but not when filtered through JDBC. Unfortunately Im using the open source DbConnectionBroker connection pooling object and I have to dig into this to apply the fix. It is suprising to me that JDBC has a problem with a database using UNICODE encoding?!? I obviously don't understand the internals of this stuff <grin> culley At 10:06 AM 9/11/01 -0700, you wrote: >Culley, > >With out more details of your setup, I can't give you a complete >answer. But check out the info at: > >http://lab.applinet.nl/postgresql-jdbc/#CharacterEncoding > >for a brief discussion of what I believe is your problem. There has also >been a number of discussions on this on the pgsql-jdbc mail list. You >might also want to check the mail archives. > >thanks, >--Barry > > >Culley Harrelson wrote: >>The was corrupted in the process of the upgrade. >>Is there some way to tell what the configuration options were when it was >>installed? I am assuming by API you mean how am I accessing Postgres? JDBC. >>Culley >> >>>X-Apparently-To: culleyharrelson@yahoo.com via web9605; 10 Sep 2001 >>>18:19:26 -0700 (PDT) >>>X-Track: 1: 40 >>>To: culleyharrelson@yahoo.com >>>Cc: pgsql-general@postgresql.org >>>Subject: Re: [GENERAL] unicode in 7.1 >>>X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 >>> =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= >>>Date: Tue, 11 Sep 2001 10:19:00 +0900 >>>From: Tatsuo Ishii <t-ishii@sra.co.jp> >>>X-Dispatcher: imput version 20000228(IM140) >>>Lines: 9 >>> >>> > my isp recently upgraded form postgreSQL 7.0 to 7.1. It went pretty well >>> > but I just discovered that non-english characters are now in the database >>> > as a question mark-- inserting non-english characters produces a ? as >>> > well. Any idea what has gone wrong and what we need to do to fix this? >>> >>>Hard to tell without knowing what the configuration option was and >>>what kind of API you are using... >>>-- >>>Tatsuo Ishii >> >>_________________________________________________________ >>Do You Yahoo!? >>Get your free @yahoo.com address at http://mail.yahoo.com >> >>---------------------------(end of broadcast)--------------------------- >>TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Culley, What do you get when you issue the following select statements: select getdatabaseencoding(); select datname, encoding from pg_database; thanks, --Barry Culley Harrelson wrote: > Ack! I guess I am hitting this problem.... > > I had my database rebuilt to use UNICODE encoding. Data now appears > correctly in pgsql but not when filtered through JDBC. Unfortunately Im > using the open source DbConnectionBroker connection pooling object and I > have to dig into this to apply the fix. It is suprising to me that JDBC > has a problem with a database using UNICODE encoding?!? I obviously > don't understand the internals of this stuff <grin> > > culley > > > At 10:06 AM 9/11/01 -0700, you wrote: > >> Culley, >> >> With out more details of your setup, I can't give you a complete >> answer. But check out the info at: >> >> http://lab.applinet.nl/postgresql-jdbc/#CharacterEncoding >> >> for a brief discussion of what I believe is your problem. There has >> also been a number of discussions on this on the pgsql-jdbc mail list. >> You might also want to check the mail archives. >> >> thanks, >> --Barry >> >> >> Culley Harrelson wrote: >> >>> The was corrupted in the process of the upgrade. >>> Is there some way to tell what the configuration options were when it >>> was installed? I am assuming by API you mean how am I accessing >>> Postgres? JDBC. >>> Culley >>> >>>> X-Apparently-To: culleyharrelson@yahoo.com via web9605; 10 Sep 2001 >>>> 18:19:26 -0700 (PDT) >>>> X-Track: 1: 40 >>>> To: culleyharrelson@yahoo.com >>>> Cc: pgsql-general@postgresql.org >>>> Subject: Re: [GENERAL] unicode in 7.1 >>>> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 >>>> =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= >>>> Date: Tue, 11 Sep 2001 10:19:00 +0900 >>>> From: Tatsuo Ishii <t-ishii@sra.co.jp> >>>> X-Dispatcher: imput version 20000228(IM140) >>>> Lines: 9 >>>> >>>> > my isp recently upgraded form postgreSQL 7.0 to 7.1. It went >>>> pretty well >>>> > but I just discovered that non-english characters are now in the >>>> database >>>> > as a question mark-- inserting non-english characters produces a ? as >>>> > well. Any idea what has gone wrong and what we need to do to fix >>>> this? >>>> >>>> Hard to tell without knowing what the configuration option was and >>>> what kind of API you are using... >>>> -- >>>> Tatsuo Ishii >>> >>> >>> _________________________________________________________ >>> Do You Yahoo!? >>> Get your free @yahoo.com address at http://mail.yahoo.com >>> >>> ---------------------------(end of broadcast)--------------------------- >>> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >> > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com >
At 11:45 AM 9/11/01 -0700, you wrote: >select getdatabaseencoding(); UNICODE >select datname, encoding from pg_database; flashcard | 5 All other databases on the server had 0 for encoding. Unfortunately my dev environment still has postgres 7.0. I updated my connection pool object and it works on dev but not on prod with 7.1. I really don't want to update my dev environment untill I can do the whole machine from scratch but I fear I might have to in order to debug this... Culley _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Culley, That all looks fine. I don't understand why you would be having problems with these settings. Are you sure you are using the 7.1 jdbc drivers? One other thing I can think of to check is to do a 'show client_encoding'. This should also return UNICODE. So to restate your problem, you get the 8bit characters returned as ?'s through jdbc, but it works correctly through psql. Is this a correct restatement of your problem? thanks, --Barry Culley Harrelson wrote: > > > At 11:45 AM 9/11/01 -0700, you wrote: > >> select getdatabaseencoding(); > > > UNICODE > >> select datname, encoding from pg_database; > > > flashcard | 5 > > All other databases on the server had 0 for encoding. > > Unfortunately my dev environment still has postgres 7.0. I updated my > connection pool object and it works on dev but not on prod with 7.1. I > really don't want to update my dev environment untill I can do the whole > machine from scratch but I fear I might have to in order to debug this... > > Culley > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com >
On Tue, Sep 11, 2001 at 11:39:38AM -0700, Culley Harrelson wrote: > Ack! I guess I am hitting this problem.... > > I had my database rebuilt to use UNICODE encoding. Data now appears > correctly in pgsql but not when filtered through JDBC. Unfortunately Im > using the open source DbConnectionBroker connection pooling object and I > have to dig into this to apply the fix. It is suprising to me that JDBC > has a problem with a database using UNICODE encoding?!? I obviously don't > understand the internals of this stuff <grin> With UNICODE you are claiming to JDBC 'hey, my data is UNICODE (UTF8)'. What encoding the data fields really are? -- marko
No this problem was fixed when I rebuild the database with UNICODE encoding. No more '?'. Now the data just gets *truncated* when it hits a non-Latin character.
Here is my classpath:
/usr/jdk1.3/jre/lib/rt.jar:/usr/jdk1.3/lib/tools.jar:/usr/jakarta-oro-2.0.1/jakarta-oro-2.0.1.jar:/usr/jakarta-regexp-1.2/jakarta-regexp-1.2.jar:/usr/jakarta-servletapi-3.2/lib/servlet.jar:/usr/jakarta-tomcat-3.2.1/lib/jasper.jar:/usr/jakarta-tomcat-3.2.1/lib/webserver.jar:/usr/Jetspeed-1.1/Jetspeed.jar:/usr/cocoon-1.8/lib/stylebook-1.0-b2.jar:/usr/cocoon-1.8/bin/cocoon.jar:/usr/xerces-1_2_0/xerces.jar:/usr/jakarta-ant/lib/ant.jar:/usr/jakarta-ant/lib/jaxp.jar:/usr/jakarta-ant/lib/optional.jar:/usr/jakarta-ant/lib/parser.jar:/usr/xalan_1_2_D01/xalan.jar:/usr/xalan_1_2_D01/bsf.jar:/usr/xalan_1_2_D01/bsfengines.jar:/usr/aoserv/lib/acme.jar:/usr/aoserv/lib/aocode-public.jar:/usr/aoserv/lib/aoserv-private.jar:/usr/aoserv/lib/damud.jar:/usr/aoserv/lib/danshome.jar:/usr/castor/castor-0.8.8.jar:/usr/cos/lib/cos.jar:/usr/ecs-1.3.3/ecs-1.3.3.jar:/usr/freemarker152/freemarker-jdk1.2.jar:/usr/gnu.regexp-1.0.8/lib/gnu-regexp-1.0.8.jar:/usr/jaf-1.0.1/activation.jar:/usr/jakarta-slide-1.0m4/slide/lib/webdav.jar:/usr/jakarta-slide-1.0m4/slide/lib/slide.jar:/usr/javachart/jars/kcServlet.jar:/usr/javamail-1.1.3/mail.jar:/usr/jdbc-2.0/jdbc-2.0.jar:/usr/jsse1.0.2/lib/jcert.jar:/usr/jsse1.0.2/lib/jnet.jar:/usr/jsse1.0.2/lib/jsse.jar:/usr/Apache-Jyve-20000907/src/java:/usr/mm.mysql-2.0.4/mm-mysql.jar:/usr/openxml/openxml-1.2.jar:/usr/ozone-0.5.5:/usr/share/pgsql/jdbc7.1-1.2.jar:/usr/pop3-1.1.1/pop3.jar:/usr/soap-2_0/lib/soap.jar:/usr/spfc-0.2.0/bin/spfc.jar:/usr/Apache-Turbine-20000907/src/java:/usr/village-1.3/village-1.3.jar:/usr/webmacro/webmacro.jar:/usr/xang_0_0_2/fesi.zip:/usr/xang_0_0_2/xang.jar:/usr/xmlrpc-java/lib/xmlrpc.jar:/usr/ApacheJSSI-1.1.2/src/java/ApacheJSSI.jar:/usr/interclient/interclient.jar:/usr/PoolMan-1.4.1/lib/PoolMan.jar:/usr/fop-0_13_0/fop_bin_0_13_0.jar:/usr/fop-0_13_0/lib/xml.jar:/wwwgroup/culley/classes:/www/flashcard/classes:/www/banyan/classes
In the same directory as the 7.1-1.2 driver is a copy of the old driver. Is there someway I could still be hitting the old one?
An interesting anomoly-- When I hit my remote production postgres server from my local tomcat (normally I'm using tomcat on the same machine as the database) non-English characters *were* displayed correctly. I was through the jdbc7.0-1.2.jar driver though! Very confusing...
I'm currently updating my local dinky little linux box with postgres 7.1.3 so my dev environment more closely matches the production. Debugging should be easier...
culley
At 04:33 PM 9/11/01 -0700, you wrote:
Here is my classpath:
/usr/jdk1.3/jre/lib/rt.jar:/usr/jdk1.3/lib/tools.jar:/usr/jakarta-oro-2.0.1/jakarta-oro-2.0.1.jar:/usr/jakarta-regexp-1.2/jakarta-regexp-1.2.jar:/usr/jakarta-servletapi-3.2/lib/servlet.jar:/usr/jakarta-tomcat-3.2.1/lib/jasper.jar:/usr/jakarta-tomcat-3.2.1/lib/webserver.jar:/usr/Jetspeed-1.1/Jetspeed.jar:/usr/cocoon-1.8/lib/stylebook-1.0-b2.jar:/usr/cocoon-1.8/bin/cocoon.jar:/usr/xerces-1_2_0/xerces.jar:/usr/jakarta-ant/lib/ant.jar:/usr/jakarta-ant/lib/jaxp.jar:/usr/jakarta-ant/lib/optional.jar:/usr/jakarta-ant/lib/parser.jar:/usr/xalan_1_2_D01/xalan.jar:/usr/xalan_1_2_D01/bsf.jar:/usr/xalan_1_2_D01/bsfengines.jar:/usr/aoserv/lib/acme.jar:/usr/aoserv/lib/aocode-public.jar:/usr/aoserv/lib/aoserv-private.jar:/usr/aoserv/lib/damud.jar:/usr/aoserv/lib/danshome.jar:/usr/castor/castor-0.8.8.jar:/usr/cos/lib/cos.jar:/usr/ecs-1.3.3/ecs-1.3.3.jar:/usr/freemarker152/freemarker-jdk1.2.jar:/usr/gnu.regexp-1.0.8/lib/gnu-regexp-1.0.8.jar:/usr/jaf-1.0.1/activation.jar:/usr/jakarta-slide-1.0m4/slide/lib/webdav.jar:/usr/jakarta-slide-1.0m4/slide/lib/slide.jar:/usr/javachart/jars/kcServlet.jar:/usr/javamail-1.1.3/mail.jar:/usr/jdbc-2.0/jdbc-2.0.jar:/usr/jsse1.0.2/lib/jcert.jar:/usr/jsse1.0.2/lib/jnet.jar:/usr/jsse1.0.2/lib/jsse.jar:/usr/Apache-Jyve-20000907/src/java:/usr/mm.mysql-2.0.4/mm-mysql.jar:/usr/openxml/openxml-1.2.jar:/usr/ozone-0.5.5:/usr/share/pgsql/jdbc7.1-1.2.jar:/usr/pop3-1.1.1/pop3.jar:/usr/soap-2_0/lib/soap.jar:/usr/spfc-0.2.0/bin/spfc.jar:/usr/Apache-Turbine-20000907/src/java:/usr/village-1.3/village-1.3.jar:/usr/webmacro/webmacro.jar:/usr/xang_0_0_2/fesi.zip:/usr/xang_0_0_2/xang.jar:/usr/xmlrpc-java/lib/xmlrpc.jar:/usr/ApacheJSSI-1.1.2/src/java/ApacheJSSI.jar:/usr/interclient/interclient.jar:/usr/PoolMan-1.4.1/lib/PoolMan.jar:/usr/fop-0_13_0/fop_bin_0_13_0.jar:/usr/fop-0_13_0/lib/xml.jar:/wwwgroup/culley/classes:/www/flashcard/classes:/www/banyan/classes
In the same directory as the 7.1-1.2 driver is a copy of the old driver. Is there someway I could still be hitting the old one?
An interesting anomoly-- When I hit my remote production postgres server from my local tomcat (normally I'm using tomcat on the same machine as the database) non-English characters *were* displayed correctly. I was through the jdbc7.0-1.2.jar driver though! Very confusing...
I'm currently updating my local dinky little linux box with postgres 7.1.3 so my dev environment more closely matches the production. Debugging should be easier...
culley
At 04:33 PM 9/11/01 -0700, you wrote:
Culley,
That all looks fine. I don't understand why you would be having problems with these settings. Are you sure you are using the 7.1 jdbc drivers? One other thing I can think of to check is to do a 'show client_encoding'. This should also return UNICODE.
So to restate your problem, you get the 8bit characters returned as ?'s through jdbc, but it works correctly through psql. Is this a correct restatement of your problem?
thanks,
--Barry
Culley Harrelson wrote:
At 11:45 AM 9/11/01 -0700, you wrote:select getdatabaseencoding();
UNICODEselect datname, encoding from pg_database;
flashcard | 5
All other databases on the server had 0 for encoding.
Unfortunately my dev environment still has postgres 7.0. I updated my connection pool object and it works on dev but not on prod with 7.1. I really don't want to update my dev environment untill I can do the whole machine from scratch but I fear I might have to in order to debug this...
Culley
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
If that is the classpath you are using then you should be using the correct code. Can you sucessfully select the data through psql? thanks, --Barry Culley Harrelson wrote: > No this problem was fixed when I rebuild the database with UNICODE > encoding. No more '?'. Now the data just gets *truncated* when it hits > a non-Latin character. > > Here is my classpath: > > /usr/jdk1.3/jre/lib/rt.jar:/usr/jdk1.3/lib/tools.jar:/usr/jakarta-oro-2.0.1/jakarta-oro-2.0.1.jar:/usr/jakarta-regexp-1.2/jakarta-regexp-1.2.jar:/usr/jakarta-servletapi-3.2/lib/servlet.jar:/usr/jakarta-tomcat-3.2.1/lib/jasper.jar:/usr/jakarta-tomcat-3.2.1/lib/webserver.jar:/usr/Jetspeed-1.1/Jetspeed.jar:/usr/cocoon-1.8/lib/stylebook-1.0-b2.jar:/usr/cocoon-1.8/bin/cocoon.jar:/usr/xerces-1_2_0/xerces.jar:/usr/jakarta-ant/lib/ant.jar:/usr/jakarta-ant/lib/jaxp.jar:/usr/jakarta-ant/lib/optional.jar:/usr/jakarta-ant/lib/parser.jar:/usr/xalan_1_2_D01/xalan.jar:/usr/xalan_1_2_D01/bsf.jar:/usr/xalan_1_2_D01/bsfengines.jar:/usr/aoserv/lib/acme.jar:/usr/aoserv/lib/aocode-public.jar:/usr/aoserv/lib/aoserv-private.jar:/usr/aoserv/lib/damud.jar:/usr/aoserv/lib/danshome.jar:/usr/castor/castor-0.8.8.jar:/usr/cos/lib/cos.jar:/usr/ecs-1.3.3/ecs-1.3.3.jar:/usr/freemarker152/freemarker-jdk1.2.jar:/usr/gnu.regexp-1.0.8/lib/gnu-regexp-1.0.8.jar:/usr/jaf-1.0.1/activation.jar:/usr/jakarta-slide-1. 0m4/slide/lib/webdav.jar:/usr/jakarta-slide-1.0m4/slide/lib/slide.jar:/usr/javachart/jars/kcServlet.jar:/usr/javamail-1.1.3/mail.jar:*/usr/jdbc-2.0/jdbc-2.0.jar*:/usr/jsse1.0.2/lib/jcert.jar:/usr/jsse1.0.2/lib/jnet.jar:/usr/jsse1.0.2/lib/jsse.jar:/usr/Apache-Jyve-20000907/src/java:/usr/mm.mysql-2.0.4/mm-mysql.jar:/usr/openxml/openxml-1.2.jar:/usr/ozone-0.5.5:*/usr/share/pgsql/jdbc7.1-1.2.jar*:/usr/pop3-1.1.1/pop3.jar:/usr/soap-2_0/lib/soap.jar:/usr/spfc-0.2.0/bin/spfc.jar:/usr/Apache-Turbine-20000907/src/java:/usr/village-1.3/village-1.3.jar:/usr/webmacro/webmacro.jar:/usr/xang_0_0_2/fesi.zip:/usr/xang_0_0_2/xang.jar:/usr/xmlrpc-java/lib/xmlrpc.jar:/usr/ApacheJSSI-1.1.2/src/java/ApacheJSSI.jar:/usr/interclient/interclient.jar:/usr/PoolMan-1.4.1/lib/PoolMan.jar:/usr/fop-0_13_0/fop_bin_0_13_0.jar:/usr/fop-0_13_0/lib/xml.jar:/wwwgroup/culley/classes:/www/flashcard/classes:/www/banyan/classes > > In the same directory as the 7.1-1.2 driver is a copy of the old > driver. Is there someway I could still be hitting the old one? > > An interesting anomoly-- When I hit my remote production postgres server > from my local tomcat (normally I'm using tomcat on the same machine as > the database) non-English characters *were* displayed correctly. I was > through the jdbc7.0-1.2.jar driver though! Very confusing... > > I'm currently updating my local dinky little linux box with postgres > 7.1.3 so my dev environment more closely matches the production. > Debugging should be easier... > > culley > > > > At 04:33 PM 9/11/01 -0700, you wrote: > >> Culley, >> >> That all looks fine. I don't understand why you would be having >> problems with these settings. Are you sure you are using the 7.1 jdbc >> drivers? One other thing I can think of to check is to do a 'show >> client_encoding'. This should also return UNICODE. >> >> So to restate your problem, you get the 8bit characters returned as >> ?'s through jdbc, but it works correctly through psql. Is this a >> correct restatement of your problem? >> >> thanks, >> --Barry >> >> Culley Harrelson wrote: >> >>> >>> At 11:45 AM 9/11/01 -0700, you wrote: >>> >>>> select getdatabaseencoding(); >>> >>> >>> UNICODE >>> >>>> select datname, encoding from pg_database; >>> >>> >>> flashcard | 5 >>> All other databases on the server had 0 for encoding. >>> Unfortunately my dev environment still has postgres 7.0. I updated >>> my connection pool object and it works on dev but not on prod with >>> 7.1. I really don't want to update my dev environment untill I can >>> do the whole machine from scratch but I fear I might have to in order >>> to debug this... >>> Culley >>> >>> _________________________________________________________ >>> Do You Yahoo!? >>> Get your free @yahoo.com address at http://mail.yahoo.com >>> <http://mail.yahoo.com/> >>
Yes, psql works fine and displays non-English characters fine. Culley At 06:05 PM 9/11/01 -0700, you wrote: >If that is the classpath you are using then you should be using the >correct code. Can you sucessfully select the data through psql? > >thanks, >--Barry > >Culley Harrelson wrote: >>No this problem was fixed when I rebuild the database with UNICODE >>encoding. No more '?'. Now the data just gets *truncated* when it hits >>a non-Latin character. >>Here is my classpath: >>/usr/jdk1.3/jre/lib/rt.jar:/usr/jdk1.3/lib/tools.jar:/usr/jakarta-oro-2.0.1/jakarta-oro-2.0.1.jar:/usr/jakarta-regexp-1.2/jakarta-regexp-1.2.jar:/usr/jakarta-servletapi-3.2/lib/servlet.jar:/usr/jakarta-tomcat-3.2.1/lib/jasper.jar:/usr/jakarta-tomcat-3.2.1/lib/webserver.jar:/usr/Jetspeed-1.1/Jetspeed.jar:/usr/cocoon-1.8/lib/stylebook-1.0-b2.jar:/usr/cocoon-1.8/bin/cocoon.jar:/usr/xerces-1_2_0/xerces.jar:/usr/jakarta-ant/lib/ant.jar:/usr/jakarta-ant/lib/jaxp.jar:/usr/jakarta-ant/lib/optional.jar:/usr/jakarta-ant/lib/parser.jar:/usr/xalan_1_2_D01/xalan.jar:/usr/xalan_1_2_D01/bsf.jar:/usr/xalan_1_2_D01/bsfengines.jar:/usr/aoserv/lib/acme.jar:/usr/aoserv/lib/aocode-public.jar:/usr/aoserv/lib/aoserv-private.jar:/usr/aoserv/lib/damud.jar:/usr/aoserv/lib/danshome.jar:/usr/castor/castor-0.8.8.jar:/usr/cos/lib/cos.jar:/usr/ecs-1.3.3/ecs-1.3.3.jar:/usr/freemarker152/freemarker-jdk1.2.jar:/usr/gnu.regexp-1.0.8/lib/gnu-regexp-1.0.8.jar:/usr/jaf-1.0.1/activation.jar:/usr/jakarta-slide-1. >0m4/slide/lib/webdav.jar:/usr/jakarta-slide-1.0m4/slide/lib/slide.jar:/usr/javachart/jars/kcServlet.jar:/usr/javamail-1.1.3/mail.jar:*/usr/jdbc-2.0/jdbc-2.0.jar*:/usr/jsse1.0.2/lib/jcert.jar:/usr/jsse1.0.2/lib/jnet.jar:/usr/jsse1.0.2/lib/jsse.jar:/usr/Apache-Jyve-20000907/src/java:/usr/mm.mysql-2.0.4/mm-mysql.jar:/usr/openxml/openxml-1.2.jar:/usr/ozone-0.5.5:*/usr/share/pgsql/jdbc7.1-1.2.jar*:/usr/pop3-1.1.1/pop3.jar:/usr/soap-2_0/lib/soap.jar:/usr/spfc-0.2.0/bin/spfc.jar:/usr/Apache-Turbine-20000907/src/java:/usr/village-1.3/village-1.3.jar:/usr/webmacro/webmacro.jar:/usr/xang_0_0_2/fesi.zip:/usr/xang_0_0_2/xang.jar:/usr/xmlrpc-java/lib/xmlrpc.jar:/usr/ApacheJSSI-1.1.2/src/java/ApacheJSSI.jar:/usr/interclient/interclient.jar:/usr/PoolMan-1.4.1/lib/PoolMan.jar:/usr/fop-0_13_0/fop_bin_0_13_0.jar:/usr/fop-0_13_0/lib/xml.jar:/wwwgroup/culley/classes:/www/flashcard/classes:/www/banyan/classes >>In the same directory as the 7.1-1.2 driver is a copy of the old >>driver. Is there someway I could still be hitting the old one? >>An interesting anomoly-- When I hit my remote production postgres server >>from my local tomcat (normally I'm using tomcat on the same machine as >>the database) non-English characters *were* displayed correctly. I was >>through the jdbc7.0-1.2.jar driver though! Very confusing... >>I'm currently updating my local dinky little linux box with postgres >>7.1.3 so my dev environment more closely matches the production. >>Debugging should be easier... >>culley >> >>At 04:33 PM 9/11/01 -0700, you wrote: >> >>>Culley, >>> >>>That all looks fine. I don't understand why you would be having >>>problems with these settings. Are you sure you are using the 7.1 jdbc >>>drivers? One other thing I can think of to check is to do a 'show >>>client_encoding'. This should also return UNICODE. >>> >>>So to restate your problem, you get the 8bit characters returned as ?'s >>>through jdbc, but it works correctly through psql. Is this a correct >>>restatement of your problem? >>> >>>thanks, >>>--Barry >>> >>>Culley Harrelson wrote: >>> >>>> >>>>At 11:45 AM 9/11/01 -0700, you wrote: >>>> >>>>>select getdatabaseencoding(); >>>> >>>> >>>>UNICODE >>>> >>>>>select datname, encoding from pg_database; >>>> >>>> >>>> flashcard | 5 >>>>All other databases on the server had 0 for encoding. >>>>Unfortunately my dev environment still has postgres 7.0. I updated my >>>>connection pool object and it works on dev but not on prod with 7.1. I >>>>really don't want to update my dev environment untill I can do the >>>>whole machine from scratch but I fear I might have to in order to debug this... >>>>Culley >>>> >>>>_________________________________________________________ >>>>Do You Yahoo!? >>>>Get your free @yahoo.com address at http://mail.yahoo.com >>>><http://mail.yahoo.com/> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
I just finished rebuilding my development environment and have duplicated the error. I have a database created with the -E UNICODE flag and I am using the jdbc7.1-1.2.jar driver. Data just gets truncated with a non-latin character without the charSet property switch, and I get a sql error when I leave in the property switch. Here is a snap of my code:
--------------------------
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
Properties props = new Properties();
Class.forName ("org.postgresql.Driver");
props.put("user","login");
props.put("password","password");
props.put("charSet","UNICODE");
conn = DriverManager.getConnection("jdbc:postgresql://url", props);
stmt = conn.createStatement();
rs = stmt.executeQuery("select 'TEST' as test");
rs.next();
String dummy = "";
dummy = rs.getString("title");
conn.close();
---------------------------------------
And when I do this I get the following SQL error:
---------------------------------------
Internal Servlet Error:
javax.servlet.ServletException:
at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:459)
at _0002fzz_0002ejspzz_jsp_464._jspService(_0002fzz_0002ejspzz_jsp_464.java:97)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)
Root cause:
java.sql.SQLException:
at org.postgresql.Connection.ExecSQL(Connection.java:533)
at org.postgresql.jdbc2.Statement.execute(Statement.java:294)
at org.postgresql.jdbc2.Statement.executeQuery(Statement.java:59)
at _0002fzz_0002ejspzz_jsp_464._jspService(_0002fzz_0002ejspzz_jsp_464.java:77)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)
---------------------------------------
If I take out the encoding line it works but truncates at any non-latin character.
culley
At 07:33 PM 9/11/01 -0700, you wrote:
--------------------------
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
Properties props = new Properties();
Class.forName ("org.postgresql.Driver");
props.put("user","login");
props.put("password","password");
props.put("charSet","UNICODE");
conn = DriverManager.getConnection("jdbc:postgresql://url", props);
stmt = conn.createStatement();
rs = stmt.executeQuery("select 'TEST' as test");
rs.next();
String dummy = "";
dummy = rs.getString("title");
conn.close();
---------------------------------------
And when I do this I get the following SQL error:
---------------------------------------
Internal Servlet Error:
javax.servlet.ServletException:
at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:459)
at _0002fzz_0002ejspzz_jsp_464._jspService(_0002fzz_0002ejspzz_jsp_464.java:97)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)
Root cause:
java.sql.SQLException:
at org.postgresql.Connection.ExecSQL(Connection.java:533)
at org.postgresql.jdbc2.Statement.execute(Statement.java:294)
at org.postgresql.jdbc2.Statement.executeQuery(Statement.java:59)
at _0002fzz_0002ejspzz_jsp_464._jspService(_0002fzz_0002ejspzz_jsp_464.java:77)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)
---------------------------------------
If I take out the encoding line it works but truncates at any non-latin character.
culley
At 07:33 PM 9/11/01 -0700, you wrote:
Culley,
I would like to help, but I'm not sure what I can do to help. If there is anything I can do, please let me know.
thanks,
--Barry
Culley Harrelson wrote:Yes, psql works fine and displays non-English characters fine.1.
Culley
At 06:05 PM 9/11/01 -0700, you wrote:If that is the classpath you are using then you should be using the correct code. Can you sucessfully select the data through psql?
thanks,
--Barry
Culley Harrelson wrote:No this problem was fixed when I rebuild the database with UNICODE encoding. No more '?'. Now the data just gets *truncated* when it hits a non-Latin character.
Here is my classpath:
/usr/jdk1.3/jre/lib/rt.jar:/usr/jdk1.3/lib/tools.jar:/usr/jakarta-oro-2.0.1/jakarta-oro-2.0.1.jar:/usr/jakarta-regexp-1.2/jakarta-regexp-1.2.jar:/usr/jakarta-servletapi-3.2/lib/servlet.jar:/usr/jakarta-tomcat-3.2.1/lib/jasper.jar:/usr/jakarta-tomcat-3.2.1/lib/webserver.jar:/usr/Jetspeed-1.1/Jetspeed.jar:/usr/cocoon-1.8/lib/stylebook-1.0-b2.jar:/usr/cocoon-1.8/bin/cocoon.jar:/usr/xerces-1_2_0/xerces.jar:/usr/jakarta-ant/lib/ant.jar:/usr/jakarta-ant/lib/jaxp.jar:/usr/jakarta-ant/lib/optional.jar:/usr/jakarta-ant/lib/parser.jar:/usr/xalan_1_2_D01/xalan.jar:/usr/xalan_1_2_D01/bsf.jar:/usr/xalan_1_2_D01/bsfengines.jar:/usr/aoserv/lib/acme.jar:/usr/aoserv/lib/aocode-public.jar:/usr/aoserv/lib/aoserv-private.jar:/usr/aoserv/lib/damud.jar:/usr/aoserv/lib/danshome.jar:/usr/castor/castor-0.8.8.jar:/usr/cos/lib/cos.jar:/usr/ecs-1.3.3/ecs-1.3.3.jar:/usr/freemarker152/freemarker-jdk1.2.jar:/usr/gnu.regexp-1.0.8/lib/gnu-regexp-1.0.8.jar:/usr/jaf-1.0.1/activation.jar:/usr/jakarta-slide-
0m4/slide/lib/webdav.jar:/usr/jakarta-slide-1.0m4/slide/lib/slide.jar:/usr/javachart/jars/kcServlet.jar:/usr/javamail-1.1.3/mail.jar:*/usr/jdbc-2.0/jdbc-2.0.jar*:/usr/jsse1.0.2/lib/jcert.jar:/usr/jsse1.0.2/lib/jnet.jar:/usr/jsse1.0.2/lib/jsse.jar:/usr/Apache-Jyve-20000907/src/java:/usr/mm.mysql-2.0.4/mm-mysql.jar:/usr/openxml/openxml-1.2.jar:/usr/ozone-0.5.5:*/usr/share/pgsql/jdbc7.1-1.2.jar*:/usr/pop3-1.1.1/pop3.jar:/usr/soap-2_0/lib/soap.jar:/usr/spfc-0.2.0/bin/spfc.jar:/usr/Apache-Turbine-20000907/src/java:/usr/village-1.3/village-1.3.jar:/usr/webmacro/webmacro.jar:/usr/xang_0_0_2/fesi.zip:/usr/xang_0_0_2/xang.jar:/usr/xmlrpc-java/lib/xmlrpc.jar:/usr/ApacheJSSI-1.1.2/src/java/ApacheJSSI.jar:/usr/interclient/interclient.jar:/usr/PoolMan-1.4.1/lib/PoolMan.jar:/usr/fop-0_13_0/fop_bin_0_13_0.jar:/usr/fop-0_13_0/lib/xml.jar:/wwwgroup/culley/classes:/www/flashcard/classes:/www/banyan/classesIn the same directory as the 7.1-1.2 driver is a copy of the old driver. Is there someway I could still be hitting the old one?
An interesting anomoly-- When I hit my remote production postgres server from my local tomcat (normally I'm using tomcat on the same machine as the database) non-English characters *were* displayed correctly. I was through the jdbc7.0-1.2.jar driver though! Very confusing...
I'm currently updating my local dinky little linux box with postgres 7.1.3 so my dev environment more closely matches the production.
Debugging should be easier...
culley
At 04:33 PM 9/11/01 -0700, you wrote:Culley,
That all looks fine. I don't understand why you would be having problems with these settings. Are you sure you are using the 7.1 jdbc drivers? One other thing I can think of to check is to do a 'show client_encoding'. This should also return UNICODE.
So to restate your problem, you get the 8bit characters returned as ?'s through jdbc, but it works correctly through psql. Is this a correct restatement of your problem?
thanks,
--Barry
Culley Harrelson wrote:
At 11:45 AM 9/11/01 -0700, you wrote:select getdatabaseencoding();
UNICODEselect datname, encoding from pg_database;
flashcard | 5
All other databases on the server had 0 for encoding.
Unfortunately my dev environment still has postgres 7.0. I updated my connection pool object and it works on dev but not on prod with 7.1. I really don't want to update my dev environment untill I can do the whole machine from scratch but I fear I might have to in order to debug this...
Culley
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com <http://mail.yahoo.com/>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Appending to my last post. I just check the postgres log and It looks like I'm getting a parser error?!? culley _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Do you mean change the encoding type of the database? culley At 11:01 AM 9/12/01 +0200, you wrote: >On Tue, Sep 11, 2001 at 05:34:29PM -0700, Culley Harrelson wrote: > > I don't understand your question > >You are saying to JDBC that it should expect UTF8 data. >Maybe with this messing around some of you data fields are eg. >latin1? > > > > > culley > > > > At 02:23 AM 9/12/01 +0200, you wrote: > > >On Tue, Sep 11, 2001 at 11:39:38AM -0700, Culley Harrelson wrote: > > >> Ack! I guess I am hitting this problem.... > > >> > > >> I had my database rebuilt to use UNICODE encoding. Data now appears > > >> correctly in pgsql but not when filtered through JDBC. Unfortunately Im > > >> using the open source DbConnectionBroker connection pooling object and I > > >> have to dig into this to apply the fix. It is suprising to me that JDBC > > >> has a problem with a database using UNICODE encoding?!? I obviously > > >don't > > >> understand the internals of this stuff <grin> > > > > > >With UNICODE you are claiming to JDBC 'hey, my data > > >is UNICODE (UTF8)'. What encoding the data fields really > > >are? > > > > > >-- > > >marko > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > >-- >marko _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
If you are getting a parse error as you said in a latter message, then you should set "debug_print_query = true" in your postgresql.conf file. This will cause the sql statements to be printed in the server log file and you then might be able to figure out why the statement sent couldn't be parsed. I noticed that the code snipit you sent below seems to have an error in it. You select 'TEST' as test, but then later you do a getString("title") which should fail since there isn't a selected column called "title". thanks, --Barry Culley Harrelson wrote: > I just finished rebuilding my development environment and have > duplicated the error. I have a database created with the -E UNICODE > flag and I am using the jdbc7.1-1.2.jar driver. Data just gets > truncated with a non-latin character without the charSet property > switch, and I get a sql error when I leave in the property switch. Here > is a snap of my code: > > -------------------------- > Connection conn = null; > Statement stmt = null; > ResultSet rs = null; > Properties props = new Properties(); > Class.forName ("org.postgresql.Driver"); > props.put("user","login"); > props.put("password","password"); > props.put("charSet","UNICODE"); > conn = DriverManager.getConnection("jdbc:postgresql://url", props); > > stmt = conn.createStatement(); > rs = stmt.executeQuery("select 'TEST' as test"); > rs.next(); > String dummy = ""; > dummy = rs.getString("title"); > conn.close(); > --------------------------------------- > > And when I do this I get the following SQL error: > > --------------------------------------- > > *Internal Servlet Error: > *javax.servlet.ServletException: > at > org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:459) > at > _0002fzz_0002ejspzz_jsp_464._jspService(_0002fzz_0002ejspzz_jsp_464.java:97) > at > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) > at org.apache.tomcat.core.Handler.service(Handler.java:286) > at > org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) > at > org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) > at > org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) > at > org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210) > at > org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) > at > org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) > at java.lang.Thread.run(Thread.java:484) > *Root cause:* > java.sql.SQLException: > at org.postgresql.Connection.ExecSQL(Connection.java:533) > at org.postgresql.jdbc2.Statement.execute(Statement.java:294) > at org.postgresql.jdbc2.Statement.executeQuery(Statement.java:59) > at > _0002fzz_0002ejspzz_jsp_464._jspService(_0002fzz_0002ejspzz_jsp_464.java:77) > at > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) > at org.apache.tomcat.core.Handler.service(Handler.java:286) > at > org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) > at > org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) > at > org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) > at > org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210) > at > org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) > at > org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) > at java.lang.Thread.run(Thread.java:484) > > --------------------------------------- > > If I take out the encoding line it works but truncates at any non-latin > character. > > culley > > > > At 07:33 PM 9/11/01 -0700, you wrote: > >> Culley, >> >> I would like to help, but I'm not sure what I can do to help. If >> there is anything I can do, please let me know. >> >> thanks, >> --Barry >> >> >> Culley Harrelson wrote: >> >>> Yes, psql works fine and displays non-English characters fine. >>> Culley >>> At 06:05 PM 9/11/01 -0700, you wrote: >>> >>>> If that is the classpath you are using then you should be using the >>>> correct code. Can you sucessfully select the data through psql? >>>> >>>> thanks, >>>> --Barry >>>> >>>> Culley Harrelson wrote: >>>> >>>>> No this problem was fixed when I rebuild the database with UNICODE >>>>> encoding. No more '?'. Now the data just gets *truncated* when it >>>>> hits a non-Latin character. >>>>> Here is my classpath: >>>>> /usr/jdk1.3/jre/lib/rt.jar:/usr/jdk1.3/lib/tools.jar:/usr/jakarta-oro-2.0.1/jakarta-oro-2.0.1.jar:/usr/jakarta-regexp-1.2/jakarta-regexp-1.2.jar:/usr/jakarta-servletapi-3.2/lib/servlet.jar:/usr/jakarta-tomcat-3.2.1/lib/jasper.jar:/usr/jakarta-tomcat-3.2.1/lib/webserver.jar:/usr/Jetspeed-1.1/Jetspeed.jar:/usr/cocoon-1.8/lib/stylebook-1.0-b2.jar:/usr/cocoon-1.8/bin/cocoon.jar:/usr/xerces-1_2_0/xerces.jar:/usr/jakarta-ant/lib/ant.jar:/usr/jakarta-ant/lib/jaxp.jar:/usr/jakarta-ant/lib/optional.jar:/usr/jakarta-ant/lib/parser.jar:/usr/xalan_1_2_D01/xalan.jar:/usr/xalan_1_2_D01/bsf.jar:/usr/xalan_1_2_D01/bsfengines.jar:/usr/aoserv/lib/acme.jar:/usr/aoserv/lib/aocode-public.jar:/usr/aoserv/lib/aoserv-private.jar:/usr/aoserv/lib/damud.jar:/usr/aoserv/lib/danshome.jar:/usr/castor/castor-0.8.8.jar:/usr/cos/lib/cos.jar:/usr/ecs-1.3.3/ecs-1.3.3.jar:/usr/freemarker152/freemarker-jdk1.2.jar:/usr/gnu.regexp-1.0.8/lib/gnu-regexp-1.0.8.jar:/usr/jaf-1.0.1/activation.jar:/usr/jakarta-slid e- >>>> >> 1. >> >>>> >>>> 0m4/slide/lib/webdav.jar:/usr/jakarta-slide-1.0m4/slide/lib/slide.jar:/usr/javachart/jars/kcServlet.jar:/usr/javamail-1.1.3/mail.jar:*/usr/jdbc-2.0/jdbc-2.0.jar*:/usr/jsse1.0.2/lib/jcert.jar:/usr/jsse1.0.2/lib/jnet.jar:/usr/jsse1.0.2/lib/jsse.jar:/usr/Apache-Jyve-20000907/src/java:/usr/mm.mysql-2.0.4/mm-mysql.jar:/usr/openxml/openxml-1.2.jar:/usr/ozone-0.5.5:*/usr/share/pgsql/jdbc7.1-1.2.jar*:/usr/pop3-1.1.1/pop3.jar:/usr/soap-2_0/lib/soap.jar:/usr/spfc-0.2.0/bin/spfc.jar:/usr/Apache-Turbine-20000907/src/java:/usr/village-1.3/village-1.3.jar:/usr/webmacro/webmacro.jar:/usr/xang_0_0_2/fesi.zip:/usr/xang_0_0_2/xang.jar:/usr/xmlrpc-java/lib/xmlrpc.jar:/usr/ApacheJSSI-1.1.2/src/java/ApacheJSSI.jar:/usr/interclient/interclient.jar:/usr/PoolMan-1.4.1/lib/PoolMan.jar:/usr/fop-0_13_0/fop_bin_0_13_0.jar:/usr/fop-0_13_0/lib/xml.jar:/wwwgroup/culley/classes:/www/flashcard/classes:/www/banyan/classes >>>> >>>> >>>>> In the same directory as the 7.1-1.2 driver is a copy of the old >>>>> driver. Is there someway I could still be hitting the old one? >>>>> An interesting anomoly-- When I hit my remote production postgres >>>>> server from my local tomcat (normally I'm using tomcat on the same >>>>> machine as the database) non-English characters *were* displayed >>>>> correctly. I was through the jdbc7.0-1.2.jar driver though! Very >>>>> confusing... >>>>> I'm currently updating my local dinky little linux box with >>>>> postgres 7.1.3 so my dev environment more closely matches the >>>>> production. >>>>> Debugging should be easier... >>>>> culley >>>>> >>>>> At 04:33 PM 9/11/01 -0700, you wrote: >>>>> >>>>>> Culley, >>>>>> >>>>>> That all looks fine. I don't understand why you would be having >>>>>> problems with these settings. Are you sure you are using the 7.1 >>>>>> jdbc drivers? One other thing I can think of to check is to do a >>>>>> 'show client_encoding'. This should also return UNICODE. >>>>>> >>>>>> So to restate your problem, you get the 8bit characters returned >>>>>> as ?'s through jdbc, but it works correctly through psql. Is this >>>>>> a correct restatement of your problem? >>>>>> >>>>>> thanks, >>>>>> --Barry >>>>>> >>>>>> Culley Harrelson wrote: >>>>>> >>>>>>> >>>>>>> At 11:45 AM 9/11/01 -0700, you wrote: >>>>>>> >>>>>>>> select getdatabaseencoding(); >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> UNICODE >>>>>>> >>>>>>>> select datname, encoding from pg_database; >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> flashcard | 5 >>>>>>> All other databases on the server had 0 for encoding. >>>>>>> Unfortunately my dev environment still has postgres 7.0. I >>>>>>> updated my connection pool object and it works on dev but not on >>>>>>> prod with 7.1. I really don't want to update my dev environment >>>>>>> untill I can do the whole machine from scratch but I fear I might >>>>>>> have to in order to debug this... >>>>>>> Culley >>>>>>> >>>>>>> _________________________________________________________ >>>>>>> Do You Yahoo!? >>>>>>> Get your free @yahoo.com address at http://mail.yahoo.com >>>>>>> <http://mail.yahoo.com/> <http://mail.yahoo.com/> >>>>>> >>> >>> _________________________________________________________ >>> Do You Yahoo!? >>> Get your free @yahoo.com address at http://mail.yahoo.com >>> <http://mail.yahoo.com/> >>
I'll try enhancing the log as you suggest-- unfortunately I'm back to my day job so my work on this will slow down... The bug you point out below isn't ever reached-- I was trying to clean out the application specific code and missed that. It has been tested with numerous working sql statements. The problem line is: props.put("charSet","UNICODE"); If I comment this line out then it works but truncates the data when reaching a non-latin character. culley --- Barry Lind <barry@xythos.com> wrote: > If you are getting a parse error as you said in a latter message, then > you should set "debug_print_query = true" in your postgresql.conf file. > This will cause the sql statements to be printed in the server log > file and you then might be able to figure out why the statement sent > couldn't be parsed. > > I noticed that the code snipit you sent below seems to have an error in > it. You select 'TEST' as test, but then later you do a > getString("title") which should fail since there isn't a selected column > > called "title". > > thanks, > --Barry > > > Culley Harrelson wrote: > > I just finished rebuilding my development environment and have > > duplicated the error. I have a database created with the -E UNICODE > > flag and I am using the jdbc7.1-1.2.jar driver. Data just gets > > truncated with a non-latin character without the charSet property > > switch, and I get a sql error when I leave in the property switch. > Here > > is a snap of my code: > > > > -------------------------- > > Connection conn = null; > > Statement stmt = null; > > ResultSet rs = null; > > Properties props = new Properties(); > > Class.forName ("org.postgresql.Driver"); > > props.put("user","login"); > > props.put("password","password"); > > props.put("charSet","UNICODE"); > > conn = DriverManager.getConnection("jdbc:postgresql://url", props); > > > > stmt = conn.createStatement(); > > rs = stmt.executeQuery("select 'TEST' as test"); > > rs.next(); > > String dummy = ""; > > dummy = rs.getString("title"); > > conn.close(); > > --------------------------------------- > > > > And when I do this I get the following SQL error: > > > > --------------------------------------- > > > > *Internal Servlet Error: > > *javax.servlet.ServletException: > > at > > > org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:459) > > at > > > _0002fzz_0002ejspzz_jsp_464._jspService(_0002fzz_0002ejspzz_jsp_464.java:97) > > at > > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) > > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > > at > > > org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177) > > at > > > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) > > at > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) > > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > > at > > > org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) > > at org.apache.tomcat.core.Handler.service(Handler.java:286) > > at > > org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) > > at > > > org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) > > at > > org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) > > at > > > org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210) > > at > > > org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) > > at > > > org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) > > at java.lang.Thread.run(Thread.java:484) > > *Root cause:* > > java.sql.SQLException: > > at org.postgresql.Connection.ExecSQL(Connection.java:533) > > at org.postgresql.jdbc2.Statement.execute(Statement.java:294) > > at > org.postgresql.jdbc2.Statement.executeQuery(Statement.java:59) > > at > > > _0002fzz_0002ejspzz_jsp_464._jspService(_0002fzz_0002ejspzz_jsp_464.java:77) > > at > > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) > > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > > at > > > org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177) > > at > > > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) > > at > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) > > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > > at > > > org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) > > at org.apache.tomcat.core.Handler.service(Handler.java:286) > > at > > org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) > > at > > > org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) > > at > > org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) > > at > > > org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210) > > at > > > org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) > > at > > > org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) > > at java.lang.Thread.run(Thread.java:484) > > > > --------------------------------------- > > > > If I take out the encoding line it works but truncates at any > non-latin > > character. > > > > culley > > > > > > > > At 07:33 PM 9/11/01 -0700, you wrote: > > > >> Culley, > >> > >> I would like to help, but I'm not sure what I can do to help. If > >> there is anything I can do, please let me know. > >> > >> thanks, > >> --Barry > >> > >> > >> Culley Harrelson wrote: > >> > >>> Yes, psql works fine and displays non-English characters fine. > >>> Culley > >>> At 06:05 PM 9/11/01 -0700, you wrote: > >>> > >>>> If that is the classpath you are using then you should be using the > > >>>> correct code. Can you sucessfully select the data through psql? > >>>> > >>>> thanks, > >>>> --Barry > >>>> > >>>> Culley Harrelson wrote: > >>>> > >>>>> No this problem was fixed when I rebuild the database with UNICODE > > >>>>> encoding. No more '?'. Now the data just gets *truncated* when > it > >>>>> hits a non-Latin character. > >>>>> Here is my classpath: > >>>>> > /usr/jdk1.3/jre/lib/rt.jar:/usr/jdk1.3/lib/tools.jar:/usr/jakarta-oro-2.0.1/jakarta-oro-2.0.1.jar:/usr/jakarta-regexp-1.2/jakarta-regexp-1.2.jar:/usr/jakarta-servletapi-3.2/lib/servlet.jar:/usr/jakarta-tomcat-3.2.1/lib/jasper.jar:/usr/jakarta-tomcat-3.2.1/lib/webserver.jar:/usr/Jetspeed-1.1/Jetspeed.jar:/usr/cocoon-1.8/lib/stylebook-1.0-b2.jar:/usr/cocoon-1.8/bin/cocoon.jar:/usr/xerces-1_2_0/xerces.jar:/usr/jakarta-ant/lib/ant.jar:/usr/jakarta-ant/lib/jaxp.jar:/usr/jakarta-ant/lib/optional.jar:/usr/jakarta-ant/lib/parser.jar:/usr/xalan_1_2_D01/xalan.jar:/usr/xalan_1_2_D01/bsf.jar:/usr/xalan_1_2_D01/bsfengines.jar:/usr/aoserv/lib/acme.jar:/usr/aoserv/lib/aocode-public.jar:/usr/aoserv/lib/aoserv-private.jar:/usr/aoserv/lib/damud.jar:/usr/aoserv/lib/danshome.jar:/usr/castor/castor-0.8.8.jar:/usr/cos/lib/cos.jar:/usr/ecs-1.3.3/ecs-1.3.3.jar:/usr/freemarker152/freemarker-jdk1.2.jar:/usr/gnu.regexp-1.0.8/lib/gnu-regexp-1.0.8.jar:/usr/jaf-1.0.1/activation.jar:/usr/jakarta-slid > e- > >>>> > >> 1. > >> > >>>> > >>>> > 0m4/slide/lib/webdav.jar:/usr/jakarta-slide-1.0m4/slide/lib/slide.jar:/usr/javachart/jars/kcServlet.jar:/usr/javamail-1.1.3/mail.jar:*/usr/jdbc-2.0/jdbc-2.0.jar*:/usr/jsse1.0.2/lib/jcert.jar:/usr/jsse1.0.2/lib/jnet.jar:/usr/jsse1.0.2/lib/jsse.jar:/usr/Apache-Jyve-20000907/src/java:/usr/mm.mysql-2.0.4/mm-mysql.jar:/usr/openxml/openxml-1.2.jar:/usr/ozone-0.5.5:*/usr/share/pgsql/jdbc7.1-1.2.jar*:/usr/pop3-1.1.1/pop3.jar:/usr/soap-2_0/lib/soap.jar:/usr/spfc-0.2.0/bin/spfc.jar:/usr/Apache-Turbine-20000907/src/java:/usr/village-1.3/village-1.3.jar:/usr/webmacro/webmacro.jar:/usr/xang_0_0_2/fesi.zip:/usr/xang_0_0_2/xang.jar:/usr/xmlrpc-java/lib/xmlrpc.jar:/usr/ApacheJSSI-1.1.2/src/java/ApacheJSSI.jar:/usr/interclient/interclient.jar:/usr/PoolMan-1.4.1/lib/PoolMan.jar:/usr/fop-0_13_0/fop_bin_0_13_0.jar:/usr/fop-0_13_0/lib/xml.jar:/wwwgroup/culley/classes:/www/flashcard/classes:/www/banyan/classes > > >>>> > >>>> > >>>>> In the same directory as the 7.1-1.2 driver is a copy of the old > >>>>> driver. Is there someway I could still be hitting the old one? > >>>>> An interesting anomoly-- When I hit my remote production postgres > >>>>> server from my local tomcat (normally I'm using tomcat on the same > > >>>>> machine as the database) non-English characters *were* displayed > >>>>> correctly. I was through the jdbc7.0-1.2.jar driver though! Very > > >>>>> confusing... > >>>>> I'm currently updating my local dinky little linux box with > >>>>> postgres 7.1.3 so my dev environment more closely matches the > === message truncated === __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
I finally got the time to set this up (fixed the column title). Here is a copy of the log data that results from the below java code: DEBUG: query: set datestyle to 'ISO'; select getdatabaseencoding() DEBUG: ProcessUtility: set datestyle to 'ISO'; select getdatabaseencoding() DEBUG: query: <FF><FE>s ERROR: parser: parse error at or near "<FF><FE>s" FATAL 1: Socket command type e unknown Does this make sense to anyone? Culley At 09:53 AM 9/12/01 -0700, you wrote: >If you are getting a parse error as you said in a latter message, then you >should set "debug_print_query = true" in your postgresql.conf file. This >will cause the sql statements to be printed in the server log file and you >then might be able to figure out why the statement sent couldn't be parsed. > >I noticed that the code snipit you sent below seems to have an error in >it. You select 'TEST' as test, but then later you do a getString("title") >which should fail since there isn't a selected column called "title". > >thanks, >--Barry > > >Culley Harrelson wrote: >>I just finished rebuilding my development environment and have duplicated >>the error. I have a database created with the -E UNICODE flag and I am >>using the jdbc7.1-1.2.jar driver. Data just gets truncated with a >>non-latin character without the charSet property switch, and I get a sql >>error when I leave in the property switch. Here is a snap of my code: >>-------------------------- >>Connection conn = null; >>Statement stmt = null; >>ResultSet rs = null; >>Properties props = new Properties(); >>Class.forName ("org.postgresql.Driver"); >>props.put("user","login"); >>props.put("password","password"); >>props.put("charSet","UNICODE"); >>conn = DriverManager.getConnection("jdbc:postgresql://url", props); >>stmt = conn.createStatement(); >>rs = stmt.executeQuery("select 'TEST' as test"); >>rs.next(); >>String dummy = ""; >>dummy = rs.getString("title"); >>conn.close(); >>--------------------------------------- >>And when I do this I get the following SQL error: >>--------------------------------------- >>*Internal Servlet Error: >>*javax.servlet.ServletException: >> at >> org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:459) >> at >> _0002fzz_0002ejspzz_jsp_464._jspService(_0002fzz_0002ejspzz_jsp_464.java:97) >> at >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >> at >> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177) >> at >> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) >> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >> at >> org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) >> at org.apache.tomcat.core.Handler.service(Handler.java:286) >> at >> org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) >> at >> org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) >> at >> org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) >> at >> org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210) >> at >> org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) >> at >> org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) >> at java.lang.Thread.run(Thread.java:484) >>*Root cause:* >>java.sql.SQLException: >> at org.postgresql.Connection.ExecSQL(Connection.java:533) >> at org.postgresql.jdbc2.Statement.execute(Statement.java:294) >> at org.postgresql.jdbc2.Statement.executeQuery(Statement.java:59) >> at >> _0002fzz_0002ejspzz_jsp_464._jspService(_0002fzz_0002ejspzz_jsp_464.java:77) >> at >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >> at >> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:177) >> at >> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) >> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >> at >> org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) >> at org.apache.tomcat.core.Handler.service(Handler.java:286) >> at >> org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) >> at >> org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) >> at >> org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) >> at >> org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210) >> at >> org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) >> at >> org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) >> at java.lang.Thread.run(Thread.java:484) >>--------------------------------------- >>If I take out the encoding line it works but truncates at any non-latin >>character. >>culley >> >>At 07:33 PM 9/11/01 -0700, you wrote: >> >>>Culley, >>> >>>I would like to help, but I'm not sure what I can do to help. If there >>>is anything I can do, please let me know. >>> >>>thanks, >>>--Barry >>> >>> >>>Culley Harrelson wrote: >>> >>>>Yes, psql works fine and displays non-English characters fine. >>>>Culley >>>>At 06:05 PM 9/11/01 -0700, you wrote: >>>> >>>>>If that is the classpath you are using then you should be using the >>>>>correct code. Can you sucessfully select the data through psql? >>>>> >>>>>thanks, >>>>>--Barry >>>>> >>>>>Culley Harrelson wrote: >>>>> >>>>>>No this problem was fixed when I rebuild the database with UNICODE >>>>>>encoding. No more '?'. Now the data just gets *truncated* when it >>>>>>hits a non-Latin character. >>>>>>Here is my classpath: >>>>>>/usr/jdk1.3/jre/lib/rt.jar:/usr/jdk1.3/lib/tools.jar:/usr/jakarta-oro-2.0.1/jakarta-oro-2.0.1.jar:/usr/jakarta-regexp-1.2/jakarta-regexp-1.2.jar:/usr/jakarta-servletapi-3.2/lib/servlet.jar:/usr/jakarta-tomcat-3.2.1/lib/jasper.jar:/usr/jakarta-tomcat-3.2.1/lib/webserver.jar:/usr/Jetspeed-1.1/Jetspeed.jar:/usr/cocoon-1.8/lib/stylebook-1.0-b2.jar:/usr/cocoon-1.8/bin/cocoon.jar:/usr/xerces-1_2_0/xerces.jar:/usr/jakarta-ant/lib/ant.jar:/usr/jakarta-ant/lib/jaxp.jar:/usr/jakarta-ant/lib/optional.jar:/usr/jakarta-ant/lib/parser.jar:/usr/xalan_1_2_D01/xalan.jar:/usr/xalan_1_2_D01/bsf.jar:/usr/xalan_1_2_D01/bsfengines.jar:/usr/aoserv/lib/acme.jar:/usr/aoserv/lib/aocode-public.jar:/usr/aoserv/lib/aoserv-private.jar:/usr/aoserv/lib/damud.jar:/usr/aoserv/lib/danshome.jar:/usr/castor/castor-0.8.8.jar:/usr/cos/lib/cos.jar:/usr/ecs-1.3.3/ecs-1.3.3.jar:/usr/freemarker152/freemarker-jdk1.2.jar:/usr/gnu.regexp-1.0.8/lib/gnu-regexp-1.0.8.jar:/usr/jaf-1.0.1/activation.jar:/usr/jakarta-slid >e- >>>1. >>> >>>>> >>>>>0m4/slide/lib/webdav.jar:/usr/jakarta-slide-1.0m4/slide/lib/slide.jar:/usr/javachart/jars/kcServlet.jar:/usr/javamail-1.1.3/mail.jar:*/usr/jdbc-2.0/jdbc-2.0.jar*:/usr/jsse1.0.2/lib/jcert.jar:/usr/jsse1.0.2/lib/jnet.jar:/usr/jsse1.0.2/lib/jsse.jar:/usr/Apache-Jyve-20000907/src/java:/usr/mm.mysql-2.0.4/mm-mysql.jar:/usr/openxml/openxml-1.2.jar:/usr/ozone-0.5.5:*/usr/share/pgsql/jdbc7.1-1.2.jar*:/usr/pop3-1.1.1/pop3.jar:/usr/soap-2_0/lib/soap.jar:/usr/spfc-0.2.0/bin/spfc.jar:/usr/Apache-Turbine-20000907/src/java:/usr/village-1.3/village-1.3.jar:/usr/webmacro/webmacro.jar:/usr/xang_0_0_2/fesi.zip:/usr/xang_0_0_2/xang.jar:/usr/xmlrpc-java/lib/xmlrpc.jar:/usr/ApacheJSSI-1.1.2/src/java/ApacheJSSI.jar:/usr/interclient/interclient.jar:/usr/PoolMan-1.4.1/lib/PoolMan.jar:/usr/fop-0_13_0/fop_bin_0_13_0.jar:/usr/fop-0_13_0/lib/xml.jar:/wwwgroup/culley/classes:/www/flashcard/classes:/www/banyan/classes >>>>> >>>>> >>>>>>In the same directory as the 7.1-1.2 driver is a copy of the old >>>>>>driver. Is there someway I could still be hitting the old one? >>>>>>An interesting anomoly-- When I hit my remote production postgres >>>>>>server from my local tomcat (normally I'm using tomcat on the same >>>>>>machine as the database) non-English characters *were* displayed >>>>>>correctly. I was through the jdbc7.0-1.2.jar driver though! Very confusing... >>>>>>I'm currently updating my local dinky little linux box with postgres >>>>>>7.1.3 so my dev environment more closely matches the production. >>>>>>Debugging should be easier... >>>>>>culley >>>>>> >>>>>>At 04:33 PM 9/11/01 -0700, you wrote: >>>>>> >>>>>>>Culley, >>>>>>> >>>>>>>That all looks fine. I don't understand why you would be having >>>>>>>problems with these settings. Are you sure you are using the 7.1 >>>>>>>jdbc drivers? One other thing I can think of to check is to do a >>>>>>>'show client_encoding'. This should also return UNICODE. >>>>>>> >>>>>>>So to restate your problem, you get the 8bit characters returned as >>>>>>>?'s through jdbc, but it works correctly through psql. Is this a >>>>>>>correct restatement of your problem? >>>>>>> >>>>>>>thanks, >>>>>>>--Barry >>>>>>> >>>>>>>Culley Harrelson wrote: >>>>>>> >>>>>>>> >>>>>>>>At 11:45 AM 9/11/01 -0700, you wrote: >>>>>>>> >>>>>>>>>select getdatabaseencoding(); >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>UNICODE >>>>>>>> >>>>>>>>>select datname, encoding from pg_database; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> flashcard | 5 >>>>>>>>All other databases on the server had 0 for encoding. >>>>>>>>Unfortunately my dev environment still has postgres 7.0. I updated >>>>>>>>my connection pool object and it works on dev but not on prod with >>>>>>>>7.1. I really don't want to update my dev environment untill I can >>>>>>>>do the whole machine from scratch but I fear I might have to in >>>>>>>>order to debug this... >>>>>>>>Culley >>>>>>>> >>>>>>>>_________________________________________________________ >>>>>>>>Do You Yahoo!? >>>>>>>>Get your free @yahoo.com address at http://mail.yahoo.com >>>>>>>><http://mail.yahoo.com/> <http://mail.yahoo.com/> >>>> >>>>_________________________________________________________ >>>>Do You Yahoo!? >>>>Get your free @yahoo.com address at http://mail.yahoo.com >>>><http://mail.yahoo.com/> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com