Page 1 of 1

XMLTYPE and Unicode

Posted: Fri 16 Dec 2011 19:34
by jdorlon
Hello,

I know that you don't support editing of XMLTYPE when OraCall.OCIUnicode := True.

Unfortunately, our customers and my managers don't stop asking for it no matter what I tell them.

Do you have plans to support it in the future, or is there some reason why you cannot?

Thanks,

John

Posted: Mon 19 Dec 2011 13:49
by bork
Hello

We don't support XMLTYPE with OraCall.OCIUnicode := True because of an Oracle Client limitation (or issue). We want to support XMLTYPE with OraCall.OCIUnicode := True, but we cannot find any good solution. We can suggest you to use parameters in all your queries. In this case you can set TOraSession.Options.UseUnicode = True and OraCall.OCIUnicode := False, and you will be able to use XMLTYPE without any limitation. Or you can wait until we find a workaround for this this Oracle Client limitation.

Posted: Mon 19 Dec 2011 14:40
by jdorlon
Hello,

Thank you for the reply and explanation. Unfortunately, setting OraCall.OCIUnicode := False is not an option for me because full unicode support is a requirement for our application.

Do you have an Oracle metalink document # that describes the problem so I can show it to my management and customers? They would be happy to encourage Oracle to get it fixed.

Thanks

John Dorlon

Posted: Tue 20 Dec 2011 10:26
by bork
Hello

The OraCall.OCIUnicode option should be set to True in two cases:
1. If you use some queries like insert into my_table values (1, 'non-english text') instead of insert into my_table values (:param1, :param2)
2. If you have tables, table columns, stored procedures or other DB objects with names that are not in English
In other cases setting the TOraSession.Options.UseUnicode option to True is enough for full unicode support.

Unfortunately, all OCI functions for using XMLTYPE are not documented, therefore it is a problem to find any similar issues on the metalink. Maybe when OCI functions for using XMLTYPE are released, the issue with OraCall.OCIUnicode=true will be fixed.

Posted: Tue 20 Dec 2011 14:28
by jdorlon
Hello,

Thank you for your reply. I didn't know why there were 2 unicode settings before.

We still need to have OCIUnicode set to true. Our users can write and execute their own queries, so it is definitely possible they will write insert statements with non-english literal values.

John

Posted: Thu 22 Dec 2011 10:56
by bork
Hello

We understand the significance of XMLTYPE support with OCIUnicode set to True. We will notify you as soon as this issue is resolved.