Обсуждение: Fwd: Re: unicode in 7.1

Поиск
Список
Период
Сортировка

Fwd: Re: unicode in 7.1

От
Culley Harrelson
Дата:
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


Re: Fwd: Re: unicode in 7.1

От
Tatsuo Ishii
Дата:
> 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

Re: Fwd: Re: unicode in 7.1

От
Culley Harrelson
Дата:
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


Re: Fwd: Re: unicode in 7.1

От
Barry Lind
Дата:
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
>



Re: Fwd: Re: unicode in 7.1

От
Culley Harrelson
Дата:
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


Re: Fwd: Re: unicode in 7.1

От
Barry Lind
Дата:
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
>



Re: Fwd: Re: unicode in 7.1

От
Culley Harrelson
Дата:

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


Re: Fwd: Re: unicode in 7.1

От
Barry Lind
Дата:
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
>



Re: Fwd: Re: unicode in 7.1

От
Marko Kreen
Дата:
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


Re: Fwd: Re: unicode in 7.1

От
Culley Harrelson
Дата:
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

Re: Fwd: Re: unicode in 7.1

От
Barry Lind
Дата:
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/>
>>



Re: Fwd: Re: unicode in 7.1

От
Culley Harrelson
Дата:
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


Re: Fwd: Re: unicode in 7.1

От
Culley Harrelson
Дата:
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-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

Re: Fwd: Re: unicode in 7.1

От
Culley Harrelson
Дата:
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


Re: Fwd: Re: unicode in 7.1

От
Culley Harrelson
Дата:
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


Re: Fwd: Re: unicode in 7.1

От
Barry Lind
Дата:
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/>
>>



Re: Fwd: Re: unicode in 7.1

От
Culley Harrelson
Дата:
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

Re: Fwd: Re: unicode in 7.1

От
Culley Harrelson
Дата:
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