> Using IBO4.x and a simple test, I am able to store Unicode data in
> the database only if I set the CharSet property of TIB_Connection to
> Unicode_FSS.

...

> However, not all columns in my database is of the Unicode_FSS type.
> In fact, there's only one column in one table that is of the
> Unicode_FSS type. Therefore, I do not want to set the CharSet
> property at the connection level, but rather at the column level
> (actually, are there any side effects if the IBO charset is unicode
> but 99% of the columns are using the WIN1252 character set?).

I have not tested, but AFAIK ib/fb does provide some automatic
transliteration between most defined character sets (except NONE).
So using a connection character set of unicode may be acceptable,
posting this question to ib_support could get a more reliable
answer to this part of the question :-)

To quote a response from Helen concerning a question about using
ISO8859_1 character set (from back in June)...

- - -
IBO will accept a non-parameterised literal string with the
identifier, e.g.

insert into category (categorycode, title, test_iso)
values ('ZZq', 'k', _ISO8859_1 'ü')

but this doesn't work:

insert into category (categorycode, title, test_iso)
values ('ZZq', 'k', _ISO8859_1 :AParam)

Perhaps you could experiment with the ::SQL:: marker infix that tells
IBO not to parse - I've never been quite sure how to do this
correctly. Alternatively, perhaps you could write stored procedures
for updating the ISO8859_1 columns...
- - -

One implication behind this suggestion is that you *could* setup a
fully dynamic insert statement that converts your input into a string
literal and prepares and executes the insert directly.


The way I worked around the problem of mixed character sets in my
DBak application was to revert to BLR. By writing selects and
inserts in BLR it is possible to detect and specify character sets
on a column by column basis. The DBak source includes some classes
for automatic BLR generation but the capabilities are very limited.


Another way around the problem is to take advantage of two phase
commits. That is; Setup a separate connection for maintenance of
the unicode column, and have the transaction connected to both
connections.


Not sure if there may be other alternatives, but these are the ones
I know about.

--
Geoff Worboys
Telesis Computing