So far everything looks fine,
no measurable performance impact,
tested heavy inserts and aggregate selects with subselects.

maby it's faster with this fusion than 100% utf8,
fb's udf and internal functions may be snappier,
but it of course has it's limitations when sending
utf8-chars not supported by ansi...

(and win1252 is up to 3 chars in utf8).

//regards

28 okt 2008 kl. 09.09 skrev tjelvar eriksson:

> Yes I'm aware of that
> (and isn't win1252 all covered by 1- or 2-chars in utf8?)
>
> My main concern is if fb is built to do it and by this, stable enough.
>
> I'll report back with loose benchmarks.
>
> all the best,
> //t
>
> 28 okt 2008 kl. 06.31 skrev Kjell Rilbe:
>
> > tjelvar eriksson wrote:
> > > Possible solution:
> > > create db with utf8
> > > on char/varchar, CHARACTER SET WIN1252 COLLATE PXW_SWEDFIN
> > >
> > > fb reports back what seems like utf8 to client.
> > > sorting is CI and localized. Tested with flamerobin and over odbc/
> > ms-
> > > access.
> >
> > This would limit your data to the character set WIN1252, but I
> assume
> > you're aware of that and that you've concluded that it's ok.
> >
> > You will get a lot of transliteration between fixed-width 8 bit
> > WIN1252
> > and variable-width 1-6 byte UTF8 when storing and retrieving data
> > into/from that column. Might be a performance issue - only you can
> > judge.
> >
> > Kjell
> > --
> > --------------------------------------
> > Kjell Rilbe
> > DataDIA AB
> > E-post: kjell@...
> > Telefon: 08-761 06 55
> > Mobil: 0733-44 24 64
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>

[Non-text portions of this message have been removed]