Thanks to Christopher Coleman.

I think the following.

As for type of returning value from RAISE EXCEPTION - CHAR or NCHAR -
it's all the same. I use NCHAR for data which take part in ORDER BY
only. CHAR type works with russian symbols correctly. Another fact:
RAISE EXCEPTION -746, 0, msgtxt
works nice with Client SDK 2.5!
works wrong with Client SDK 2.8 and 2.9

Table for message logging: we have it. We use a simple procedure which
1) inserts messages into this table
and/or 2) execute this RAISE EXCEPTION, depending on message level.
Procedure is call out from thousands points, including hundreds of triggers.
We need everybody see our messages (with appropriate level) immediately
regardless of application and operation system.

Generate message by application and numeric key - it is not enough.
Trigger must say about logical mistake when SQL query is come from
dbaccess, WinSQL, Delphi program, etc. Every so often say in Russian
to user, not administrator only.

As result we can't upgrade Client SDK 2.5 now.
--
Julian Zalutsky MIS
cis@tut.by Computer Information Systems Ltd
+375 0(162) 21-42-39 Brest, Republic of Belarus

>> I have a problem: client program doesn't see national symbols
>> in error message from SP commands:
>> LET msgtxt = 'russian phrase';
>> RAISE EXCEPTION -746, 0, msgtxt;
>>
>> But following commands works nice:
>> SELECT russian_text_field FROM Any_Table;
>> UPDATE Any_Table SET russian_text_field = 'any national text';

> You mentioned that the environment variables, connection strings,
> and CSDK don't change, and you tried two engine versions, so I
> suspect RAISE EXCEPTION is not returning an NCHAR. Unfortunately, I
> could not find anything to confirm this, so you are left opening a
> case with Informix support to find out if this is a known issue.
> From them, you will probably hear a lot of encouragement to get off
> of 9.21. Actually, many on this list would probably echo that.

> As a sort of workaround, perhaps you could put the error message
> in a table, possibly temp and have the application pull it out of
> there, or else just send the exception and let the app generate the
> message. This, of course, depends, on what you need in msgtxt.

> In our app, we have a log table we put all significant diagnostic
> messages in. If you have something like that, maybe you could raise
> the exception and msgtxt could be the numeric key to the
> diagnostic_log row.
.. . .
> Christopher Coleman