Re: Very strange Error in Updates - Worst than ever !

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(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 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. Fassi

SISTEMATICA ingenieria de software srl
<http://www.sistemat.com.ar>Ituzaingo 1628 (2000) Rosario, Santa Fe,
Argentina.
Tel / Fax: +54 (341) 485.1432 / 485.1353