Re: Very strange Error in Updates

Oliver , you are right !  It's no semantic , the problem remain.

But you can explain why the *exactly* sames values can be inserted  and
not updated ?

And why via ODBC ,  the same statements with the same servers and with
the same Dbs , run without problem ?

Dario.

Oliver Jowett wrote:

> Dario V. Fassi wrote:
>
>> Server 7.3.4  for W2K and Linux too.
>> Encoding SQL_ASCII  in both cases.
>>
>> I understand the source of the problem  , but the ASCII encoding  are
>> not 7 bits , it has 8 bits with international charsets in codepages,
>> like values in examples.
>> You are talking about US-ASCII charset , that is a Unicode subset of
>> 7 bits.
>
>
> You're arguing over nomenclature here. At the end of the day, a
> postgresql database encoding of SQL_ASCII means 7-bit ASCII; if you
> call that US-ASCII, fine, but it doesn't change the problem. With an
> encoding of SQL_ASCII the server does not have sufficient information
> to translate characters >127 between the database encoding and
> UNICODE, which is required by the JDBC driver (even if the JDBC driver
> did not set client_encoding to UNICODE, it'd still have to somehow do
> this translation itself since Java strings are represented as UTF-16).
>
> See http://www.postgresql.org/docs/current/static/multibyte.html for
> some more details. The JDBC driver will always use a "client character
> set" of UNICODE when talking to a >= 7.3 server.
>
>> No matter that , and speaking in CHARS , if  I'm putting a 30 chars
>> length string at a field of 30 chars length ,
>> I think that the driver can/must assure, a 30 chars length string
>> transfer.
>> May be a "data truncation" warning can be acceptable, or a
>> replacement byte/char, or cutting the eight bit ,
>> but it's no sufficient reason to abort the update.
>>
>> What 's your opinion ?
>
>
> The server already does a replacement -- the problem is that the
> replacement may be longer than one character (see the referenced docs
> above for handling of unrepresentable characters). So the server-side
> representation of a "30 character" Java string may actually be longer
> than 30 characters in the database encoding.
>
> Either way there's nothing the driver can really do about it -- we
> don't want to duplicate all the knowledge about charset conversions on
> the driver side (currently, the driver does know some details about
> encodings, but that's only there to support pre-7.3 servers). We just
> hand off a valid UNICODE string and let the server deal with it. If
> the server generates an error and aborts the transaction -- too bad,
> it's not the driver's fault.
>
> The best option is to fix your database encoding; UNICODE is your best
> bet if you're only talking to it via JDBC. If you really want silent
> truncation (bad idea!) you can get that via an explicit cast to
> varchar(30) in your query.
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
>