Helen:

Thank you for your answer.

Before doing the test suggested in the file metadata_charset.txt using isql, I made a backup and restore of each database with FireBird 2.1.2. So they were already upgraded to ODS 11.1.

I have no stored procedures, triggers, views, or CHECK constraints that use literal strings with non english caracters (spahish letters with accents or something similar). Obviously my application uses a lot of WHERE clauses and surely sometimes they have non english caracters, but they are made "on the fly" when the user uses the application and they are not stored in objects of the database.

I don't understand exactly what do you mean when you say "user data stored in blobs in character set NONE". In the databases there are many blob fields with non english caracters, but I checked the data after the backup and restore process and the spanish accents are where they have to be and I can read them perfectly.

Then does this means that for my databases, it is enough if the only thing I do is backup and restore?

P.S.: I wrote this message directly from yahoogroups in the web because if I write from my Outlook Express as usually, apparently the message doesn´t arrive to the group. Is this my problem only or it´s a general problem of the group?

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 07:47 AM 1/06/2009, you wrote:
> >I suppose my databases only use ASCII, but may be I don't understand exactly
> >the problem. I read the file metadata_charset.txt, made a copy of one
> >database, open a DOS window, and did the following:
> >
> >First:
> >
> > - 1. isql database.fdb
> > - 2. SQL> input 'metadata_charset_create.sql';
> > - 3. SQL> exit;
> >
> >Then:
> >
> > - 1. isql database.fdb
> > - 2. SQL> select * from rdb$check_metadata;
> > - 3. SQL> exit;
> >
> >I saw a lot of lines on the screen mentioning objects of the database and
> >ending with "<null>" but I didn't see any exception.
> >
> >I did the same with copies of other databases with the same result.
> >
> >That means there is no need to do anything with the original databases?
>
> Only you can know that.
>
> If you created any stored procedures, triggers, views, or CHECK constraints, that contained any characters that are not from the USASCII (alias ASCII7) codepage, then your source and blr blobs will need fixing to use with v.2.1. That is what the scripts are for: to fix the transliteration problems *in metadata*. Such characters are mostly likely to occur in comments and in the arguments for WHERE clauses.
>
> The databases need to be upgraded to ODS 11.1 *first* (by taking a backup under the v.2.0.x server and restoring it under the v.2.1 server). If you can't figure out whether it affects your upgraded databases, then take backups of these upgraded (v.11.1) databases under the 2.1 server, restore them under the 2.1 server and attempt to alter a few of these affected object types.
>
> It will also affect user data stored in blobs in character set NONE, *if* they contain non-ASCII7 characters *and* you are using a Unicode character set for the client connection. No problems if your character set and codepage already support those characters.
>
> Do please understand that porting your sites to the 2.1.x server series is not as trivial as jumping a point release or two from 2.0.something to 2.0.5. I think it would be quite inadvisable for you to hope it will "just work" without understanding the changes and thoroughly testing the apps with actual customer data.
>
> ./heLen
>