no, comparing was just an example..as i said earlier, what i need is a
udf that searches for substring in my unicode_fss fields and replaces
them with a different substring..so i was thinking that whether this
replacing takes place byte by byte or character by character shouldnt
in fact matter...only im not so sure whether a unicode string might
have oll of a sudden contain a 0-byte in the middle of it, in which
case an ansi routine would 'think' it has reached the strings end when
in fact it goes on

--- In firebird-support@yahoogroups.com, "Ivan Prenosil"
<Ivan.Prenosil@...> wrote:

>
> > MY understanding of UNICODE_FSS was that it is a 'wide' string

format,

> > and that 24bits per character were used, so 3 bytes.
>
> No, one character is 1 or 2 or 3 bytes.
> It is the reason why it is not a good idea to use CHAR datatype with

Unicode_fss,

> because CHAR by definition uses fixed buffer length, e.g. if you have
> CHAR(2) CHARACTER SET UNICODE_FSS
> you can store 'ABCDEF' into it because each ASCII char is one byte only.
>
>
> > So when you compare
> > strings you do not have to do anything other than a simple byte by

byte

> > comparison.
>
> In fact you _can_ compare Unicode_fss strings byte by byte
> (if what you want is binary collation).
>
> Ivan
> http://www.volny.cz/iprenosil/interbase/
>