>I have more than 250 firebird databases which my users use with my erp software. When I
>was develop that database it was on Firebird 1.5 and I use UNICODE_FSS collation driver
>for my VARCHAR fields. After that I was migrate (update) this databases to 2.0 than 2.1
>and now I was updated this databases to 2.5 but UTF8 collation.
>
>So here is a main problem. When I was designed table Articles it has for example field
>Name, ExtraName, ... which is VARCHAR(50). My Firebird database allow my users to
>insert 150 char long word into field which is 50 char long. Now, I decide to made brand
>new database with fields VARCHAR(150) instead of VARCHAR(50) in earlier version of
>database, and i must to migrate to UTF8 because UNICODE_FSS was very bad solution, and
>just to keep all data because users doesn't know that some values longer than 50 chars.
>And it is now extremly slow when I compare speed now and before and now I need some
>trick to decrease field size but to not copy data from one to another database, because
>I took a lot of time to my users which has very large database and now all works slow
>and I have a little problem...

I wonder exactly what is slow. It would surprise me greatly if

SELECT 1
FROM MyTable
WHERE MyVarCharField = 'Privet'

was noticeably different depending on the length of MyVarCharField. What wouldn't surprise me was if PLANs changed for queries between Firebird versions or possibly even character sets/collations (I don't know if collations can influence plans, but can imagine that WHERE UPPER(MyVarCharField) = 'POKA' can use a different plan depending on whether the collation is case sensitive or not). So, could you specify more exactly what is slower?

Set