--- In firebird-support@yahoogroups.com, Svein Erling Tysvær <svein.erling.tysvaer@...> wrote:

>
> >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
>

Hello Set,

I have n-tier application set up, it mean, firebird as backend database, application server as business logic and thin client as front end. So if database works fine, transport between database and thin client is slower. If delphi from varchar field which is long 150 char get 150 char and tranfer it to client and those chars are UTF8 it could be slower, I think...

Sasa