Subject Downsides of UNICODE_FSS in connection string ?
Author Jerome Bouvattier
Hello,

I'm new to UNICODE (and charsets in general)...

I have a db where most of the fields prone to be searched/compared/sorted
are stored as ISO8859_1. Only some description fields must be stored as
UNICODE_FSS.
In my connection string, I specify UNICODE_FSS as the charset. I have learnt
how to do my translations in Delphi (which does not support UNICODE) and so
far, it looks like I've got something working.

However, in order to avoid later "surprises", I'd be glad if you could
answer the following questions :

Does adding UNICODE_FSS to the connection string come with some downsides ?
In particular,

- Should I expect any performance drop for the common operations on
ISO8859_1 fields ?
- Will I have to tweak my SQL statements to take this mixed charsets
scenario into consideration ?
- Provided I enforce in my client app the use of ASCII characters to define
WHERE conditions on ISO8859_1 fields, will I have to use introducers ?

Anything else I should be aware of ?
Any other possible setup maybe ?

Thanks.

--
Jerome