At 05:17 PM 21-06-02 +0200, you wrote:

>Hi,
>
>I have got a table with the following definition:
>
>CREATE TABLE T_DOKUMENTVORLAGEN (
> NUMMER NUMERIC(18,0) NOT NULL,
> DOKUMENTNAME VARCHAR(30) CHARACTER SET ISO8859_1 NOT NULL COLLATE
>DE_DE,
> DOKUMENTTYP VARCHAR(1) CHARACTER SET ISO8859_1 NOT NULL COLLATE
>DE_DE,
> DOKUMENT BLOB sub_type 0 segment size 8192);
>
>I am using a TIB_DSQL to insert records.
>When I am trying to insert a value for "Dokumentname"
>which contains a German Umlaut (eg. äöü) I get the
>following error: "Cannot transliterate character between character
>sets".
>
>I have learned that I have to change the Charset property of my
>IB_Connection to ISO8859_1 so that it works.
>
>Now my question is:
>I have got an existing production database where all tables use the
>charset NONE, but I would like to create some new tables with ISO8859_1.
>
>So my question is: will an IB_Connection with its Charset set to
>ISO8859_1
>be able to work with the old tables or will errors occur?
>Can a connection using ISO8859_1 read and write tables which are defined
>as character set NONE?

Short answer: yes.
Complicated answer: a column defined as character set NONE will accept
characters into it from character set ISO8859_1 without
complaining. However, if your client is connected using ISO8859_1 as the
client character set, you will get the transliteration error when you
attempt to >select< that row.

So you have a number of issues confronting you and I don't know all of the
answers.

1. If you use ISO8859_1 for your client connection, you will have to
ensure *absolutely* that nobody can enter "ISO8859_1-only" characters into
your charset NONE columns. (They can be written but they can't be read).

2. If you stay with NONE for your client connection, your NONE columns
will be OK but you will have to "cast" all of the write strings for your
ISO8859_1 columns explicitly, i.e., prefix the strings with the _ISO8859_1
identifier (This is a keyword, not a string, so it is not quoted). This
has limitations with parameterised entries as the IBO parser seems not to
recognise the character set identifier.

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

3. Another alternative is to recreate all of your character columns to be
ISO8859_1, use ISO8859_1 for your client connections and not worry about
transliteration errors at all.

Don't take this as the "last word" on it. There could well be some little
trick in IBO that lets you do this in a simple way.

regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com