""Riho-Rene Ellermaa"" <r.ellermaa@...> wrote in message
news:EB7F4A56326E97468392D1FB7684CE9C31AF04@......

>
> When I open USERS2 table (or USERS view) with IBAdmin, I can enter

accented characters into FIRST_NAME and LAST_NAME.

SQL> show table users;
USER_NAME = VARCHAR(128) CHARACTER SET ASCII Nullable
...
FIRST_NAME =VARCHAR(32) CHARACTER SET UNICODE_FSS Nullable DEFAULT
UNICODE_FSS ''

Do you see the difference between the two fields, right? User names are
strictly ASCII characters, follow them. If you don't want to be in sync,
enjoy problems.

> When I do the same with isc_add_user, I get the 335544754 error.

It would be better if you add the message to the error number. Make easier
for others to follow you, where possible. Your error is:

Arithmetic exception, numeric overflow, or string truncation
Cannot transliterate character between character sets

Even with that mother of bugs (ibconsole) I can replicate the problem by
using the User Security option and entering an accented user name. Ibconsole
uses the API, it doesn't write directly into isc4.

> Does isc_add_user check the strings before it enters them into database or

what?

No. A transliteration error is the inability to piggyback a character from
the source charset to the target charset. The API uses charset NONE = zero.
The table field uses charset ASCII = two. When you write in charset NONE a
character that's out of the first 127 ASCII codes, it can't be safely
converted to the equivalent character in ASCII, just because the only
standarized codes are the first 128. The rest is an extension to ASCII and
can't be converted. To go from NONE to ASCII, the engine goes from NONE to
UNICODE and then from UNICODE to ASACII. But when going to UNICODE,
cvt_none_to_unicode() says:

* Functional description
* Convert CHARACTER SET NONE to UNICODE (wide char).
* Byte values below 128 treated as ASCII.
* Byte values >= 128 create CONVERT ERROR

What's interesting is that internally the engine knows the position in the
string that failed, but that information is not passed to the user.

When you login directly into isc4, you can use ASCII as the preferred
charset and then input invalid user names from the engine POV, because
copying strings with the same charset is a raw copy, there's no validation
for invalid characters. The source is assumed to be valid. But if you use
charset NONE, you will see the same error than through the API.

I will tell you only for a second time: don't use special character in user
names, stick to the classic ASCII table (first 128 characters) and more
even, use the visible characters. You can assume safely that any field name
that can be written without needing double quotes around is a valid user
name. When the engine compares user names, it does so by simply uppercasing
them, since they are case-insensitive. That uppercasing is strictly
ASCII-based. In common.h

#define UPPER7(c) (((c) >= 'a' && (c)<= 'z') ? (c) - 'a' + 'A' : (c))

Hence, a user name with a cute accent has no chance to be matched by the
engine when uppercased. This remembers me how kangaroo is a meaningless name
(semantic error) and the sound was further deformed in Spanish
(transliteration error).

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing