SQL_ASCII is not really an encoding, it is more the lack of any encoding
support from the server. With this setting the encoding is fully the
responsibility of the client application.
This is very comfortable for special cases but for most regular cases it is
only asking for troubles.
Therfore for most cases UTF8 should be the prefered encoding on the server
side. The client encoding only tells the server how to convert the data from
and to the client. How to set this depends on the capabilities of the client.
In the manual in chapter 22.2 Character Set Support you can get more details
and all from the server supported conversions.
Best regards
Ivo
Am Dienstag, 26. Februar 2008 20.41:45 schrieb Carol Walter:
> Greetings...
>
> I'm really confused about something. I hope you'll help. I have a
> client who wants to use Asian Character data. The database he wants
> to use is set to SQL_ASCII, the default. I thought there might be an
> ALTER DATABASE command that would change this, but I've been through
> the documentation and it says that encoding is done at the client
> level and is changed with a set statement. I assumed that would be
> like setting the search path so I tried it and I was able to set the
> encoding for my session to UTF8. I guess my question is how does
> this work, where the database is set to use one encoding sequence and
> it is set for the client session to something else.
>
> Carol Walter
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
