Thomas Steinmaurer schrieb:

> > > I'll try it, I just hope I don't have to add the collation order to
> > > every one of 10,000 varchar fields :-(
> >
> > You shoulkd think about using domains and adding the collation order to
> > it!
>
> this is the clean (always prefered) solution to go.
>
> but if you need a fast "dirty solution" without using domains you could do
>
> 1) First dirty solution for newly databases
>
> a) extract your database metadata
>
> b) create a clean database with your choosen character set (WIN1252 should
> be fine). for example:
>
> CREATE DATABASE
> 'servername:/path/file.gdb'
> PAGE_SIZE 4096
> DIALECT1
> USER 'SYSDBA' PASSWORD 'masterkey'
> DEFAULT CHARACTER SET WIN1252;
>
> Don't run your metadata script at this time.
>
> c) Connect to your newly created database with a given user who should be
> the owner of all database objects.
>
> execute:
>
> UPDATE RDB$CHARACTER_SETS SET RDB$DEFAULT_COLLATE_NAME = 'PXW_INTL850'
> where RDB$CHARACTER_SET_NAME = 'WIN1252';
>
> => each newly created character field is created with database default
> character set (WIN1252) and collation PXW_INTL850
>
> d) run your metadata script
>
> Be aware that after each backup/restore the default collation PXW_INTL850
> for WIN1252 in RDB$CHARACTER_SETS is resetted to collation WIN1252
>
> 2) Second dirty solution for existing databases
>
> a) hacking system tables

Oh, it's about dirty solutions...

Okay here's some code for that:

Have a look at RDB$FIELDS.
The last two fields are:
RDB$COLLATION_ID (for WIN1252 that's: 2)
and
RDB$CHARACTER_SET_ID (for WIN1252 that's 53)

But you should really drop all the necessary indexes before that and try
to recerate them afterwards.

Luc.