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

> In Interbase 6 manual (Table 6.4) there is
> isc_error_adding_sec_record - 335544754 - error while attempting to add

the user

>
> Of course your message gives out much more information.
> Where did you get your message? Am I using wrong literature.

I got the "transliteration error" while trying to add a non-ASCII user name
with IBConsole. No tricks. I used the option to manage security. Then I
tried to do the same directly editing the USERS table and got the same
message.

> About user names - I accept the ASCII usernames (USER_NAME) , but I'm

talking now about first and last names - they are unicode fields. Or am I
missing something.

You aren't missing anything. This will make you happy because you aren't
silly but will make you sad because you hit one of the multiple quirks in
the services API and in the three "to be deprecated later" calls that were
implemented in IB5 to add, delete and modify users. You are using one those
IB5 calls. I think that it doesn't matter if you use the Services API; you
will get the same error.

When you connect to a db, as you know, you usually specify that the
connection proceeds in the same charset than your whole db or your fields
are. The problem is that those API calls AFAIK do not carry a charset and do
not have a way to specify one. Hence, you connect in ASCII. The person's
name uses UNICODE, right. But the engine should convert from ASCII to
UNICODE and can't. It's incredible that nobody foresaw that problem when
creating those API calls. Had Borland been instead an European or South
American company, non-ASCII support throughout the product would have been a
natural goal and not a burden. The short reply is that gsec allows a role
but doesn't provide a way to specify the charset, either.

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