Hi Dave, I used pgSchema today with a Latin1 encoding hack.
Whenever a character does not exist in Latin1 (example : euro sign), an error is returned. Obviously, this is not always the case: Japanese is transformed in unreadable characters without error. My impression is that client encoding is not ***very** secure. A full unicode chain is a better solution. But we need Client encoding support as it offers a wide variety of encodings ... and is compatible with VB. Maybe we could start modifying pgSchema->Databases and pgSchema->pgDatabase. What would you think if we : - renamed EncodingName into ServerEncoding, - added ClientEncoding. Then, in frmSQLInput, we would add a combo to choose the encoding needed. This will allow me to view UTF-8 data in Latin1 and export it in UTF-8. Isn't it marvelous? Cheers, Jean-Michel
