After try *all* versions of jdbc drivers I found that the problems
1) DB with UNICODE encoding.
2) Jdbc Driver : pg74.214.jdbc2.jar (186948 bytes )
Thanks Oliver, Tom and Kris for your time and help.
Dario V. Fassi wrote:
> We do a ODBC program to migrate the DB (SQL_ASCII) to a DB with
> UNICODE encoding .
> This DB in ODBC with set CLIENT_ENCODING='UNICODE' , work fine.
> 1) Now from a JDBC java program , we read a row that has a field
> CALLE varchar(30) = 'ññññññññññññññññ' ,
> 2) then we do an Update of another field in the same row ,
> 3) then the untouched field ends CALLE varchar(30) = ''
> I'm absolutly lost in this problem.
> Oliver Jowett wrote:
>> Tom Lane wrote:
>>> Oliver Jowett <oliver(at)opencloud(dot)com> writes:
>>>> What about refusing to change client_encoding to something other
>>>> than SQL_ASCII on SQL_ASCII databases?
>>> Not sure that would do anything very useful. People who aren't
>>> about this probably aren't thinking about setting client_encoding
>>> properly, either.
>> I was thinking about it from the other angle -- clients that set
>> client_encoding and expect the server to do the conversion (e.g. the
>> JDBC driver) will see an error rather than bogus unconverted data.
>> What does the server currently do if you ask for a client_encoding
>> that isn't supported by the database encoding (e.g. LATIN1<->LATIN2)?
>> It seems to me that SQL_ASCII is kinda-sorta-if-you-squint-a-bit like
>> an encoding that doesn't support any client_encoding but SQL_ASCII.
In response to
pgsql-hackers by date
|Next:||From: lists||Date: 2004-07-16 05:55:13|
|Subject: Re: XLogWrite: write request 0/53A4000 is past end of log|
|Previous:||From: Michael Glaesemann||Date: 2004-07-16 05:33:09|
|Subject: Re: Converting epoch to timestamp |
pgsql-jdbc by date
|Next:||From: Jean-Michel Zigna||Date: 2004-07-16 07:13:05|
|Subject: Statement as a parameter of a method|
|Previous:||From: Dario V. Fassi||Date: 2004-07-16 05:27:04|
|Subject: Re: Very strange Error in Updates|