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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
