Jean-Michel POURE allegedly said:
> 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.
We currently have:
Encoding (Long)
EncodingName (String)
Maybe change these to:
ServerEncodingID (Long)
ServerEncodingName (String)
and add:
ClientEncodingID (Long)
ClientEncodingName (String)
The ClientEncodingID would be the Windows LCID (I assume that's relevant
in this case)
>
> Then, in frmSQLInput, we would add a combo to choose the encoding
> needed.
I'm not sure that's the best place. It would need to be somewhere that's
relevant to the whole connection, because that's how it would be set.
What about setting it from the Context menu (right click), and the
database properties page. We could then remember the encoding per database
in the registry for future connections.
> This will allow me to view UTF-8 data in Latin1 and export it in UTF-8.
> Isn't it marvelous?
It will be when it works :-)
Regards, Dave.
