As you’ve seen in your database, the French accented caracters are not
stored “as is” in the database. Latin1 extensions are not part of standard
Our main SQL_ASCII database is full of accented characters from the
latin1 subset, whithout any problems. AFAIK they fit into the 1 byte
address space (255 chars). What does unicode bring to the table if we
don’t plan to expand beyond western european languages? (sorry for the
ASCII and are all 2 bytes caracters in unicode. In term of sorting for
example, it may be faster with your setting, but the resulting order will be
rather strange when accented caracters come on the way. Also, when using
database functions for counting caracters in a string, you’ll get different
results (with unicode, number of caracters (bytes) in a string is between
one time and twice the number of symbols). This is a problem with setting
the size for each field (by the way, is that OK in RT? Or can we overrun
database fields by filling with double-byte only caracters an input field in
I can’t explain why you got the spurius space, but it seems to me it is
always better to use the right encoding in the database when you can.
Agreed. I just want to make sure RT requires UNICODE in its Postgres
database to properly operate and better understand the issues. It’s
possible to maintain different encodings in each database on a single
Postgres installation, so it’s not a problem for me to convert.
In any case thanks for your insight, cheers,
OENONE: Quoi ! vous ne perdrez point cette cruelle envie ?
Vous verrai-je toujours, renonï¿½ant ï¿½ la vie,
Faire de votre mort les funestes apprï¿½ts ?
(Phï¿½dre, J-B Racine, acte 1, scï¿½ne 3)