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.
Dario.
Oliver Jowett wrote:
Tom Lane wrote:
Oliver Jowett <oliver@opencloud.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 thinking
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.
-O
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
--
Dario V. FassiSISTEMATICA ingenieria de software srl
Ituzaingo 1628 (2000) Rosario, Santa Fe, Argentina.
Tel / Fax: +54 (341) 485.1432 / 485.1353
