DIRECT mode fails when working with UNICODE

[velislav]

I could not make ODAC read/write UNICODE symbols in NVARCHAR2 fields when in DIRECT mode.

I'm evaluating WinXP SP2 + Delphi 6 (with TNT Unicode VCLs) + ODAC 6.50 against Win2003 + Oracle 10GR2 running in CL8MSWIN1251

In the DB I have a table with a NVARCHAR2 field.

In Delphi my Session.Options.Direct = True and
Session.Options.UseUnicode = True, Also I have an OraQuery connected to the table and a TNTGrid.

When try to write Über ( a word in Deutsch) in a TNTGrid and save it to DB I can see the word correct in TNTDBGrid but when I POST to DB, it loses the special symbol(Ü). I've also get the same problem trying to write Turkish and Spanish words containing non-standard latin symbols.
The only non-latin symbol I write/read successfuly are Bulgarian letters (I suppose because of the server CHARACTERSET).

The most strange thing is
If I set Session.Options.Direct = False I can read and write unicode symbols from/to the DB without any limitations.

In this forum I came upon this topic http://devart.com/forums/viewtopic.php?t=12200

So I've tryed to connect using Options.Charset = 'CL8MSWIN1251' and ''
Also I've changed session parametes on Session.OnAfterConnect through
ALTER SESSION SET NLS_LANGUAGE = 'BULGARIAN';
ALTER SESSION SET NLS_TERRITORY = 'BULGARIA';

but nothing led to successful writing to DB.

As I have no problems when using ODAC through Oracle client I suppose there is a missfunction in ODAC VCL when in DIRECT mode.

Please give me some direction how to use ODAC in DIRECT mode in my situation.

[Plash]

We have reproduced this problem, and we are working on it. You will be notified when we fix the problem.

[velislav]

I've posted the problem I came upon in my tests a month ago. Do you have any progress with the problem? When can I expect a fix?

[Plash]

We have fixed this problem. The fix will be included in the next build of ODAC.

[MLerch]

In a previous thread you said:

> We have added support for OCI Unicode Environment in ODAC 6.70. But it is disabled by default because OCI has some bugs with Unicode Environment.

Can you speak about this, will there be a commercially viable release of ODAC soon to support Unicode given that there are OCI bugs in Unicode environments?

Thanks,
Mark

[Plash]

The current ODAC build can be used to work with Unicode. Set the UseUnicode option of TOraSession to True. In this case ODAC can read and write data in Unicode. This feature does not use OCI Unicode Environment, and the mentioned bugs are not related to this option.

OCI Unicode Environment is required to use Unicode characters in the SQL property of ODAC components. It can be used only in ODAC for Delphi 2009 or Unicode build of ODAC for Delphi 2007. In most cases you don't need Unicode characters in the SQL property. You can use parameters of WideString data type instead. If you still need this feature, try to enable it. Some OCI features does not work with Unicode Environment, but maybe you application does not use these features.

[MLerch]

Thanks for your reply. Do you by any chance have a link to an Oracle site which enumerates the various OCI issues in a Unicode environment? I wasn't able to find anything. Because we will be needing to assign to SQL properties and thus will use the OraCall.OCIUnicode := True;

[Plash]

The limitations of OCIUnicode are the following:

- Direct Path Loading using TOraLoader is supported starting from Oracle client 10.2;
- some operations with TIMESTAMP data type are supported starting from Oracle client 10.2;
- fields of XMLTYPE cannot be edited;
- LOB attributes of OBJECT fields cannot be edited.