Devart Forums

Hi there,

we're currently a very strange issue on some few machines. Unfortunatelly on one of our productive target systems. That's why we need help.

The target system has Windows 7 Enterprise x64 installed. It has a complete fresh setup with Devart DotConnect 7.2.104.0 and connects to a remote Oracle Database 11g Release 11.2.0.3.0 - 64bit.

We try to write a simple xml string into a column of type Clob through the Entity Framework. The string "leaves" our application as a valid UTF-8 string and "arrives" in the database as a modified string containing a "\0" after every character. So passing in something like "<LisSettings ..." results in "<\0L\0i\0s\0S\0e\0t\0t\0i\0n\0g\0s\0 ..."
Having those values in the database causes lots of problems in handling this string.

Unfortunatelly I won't be able to provide a sample project since we only have two systems where this problem occurs. I have documented as much as possible with screenshots, using DBMonitor to track what's going into the database. If you provide me an email address I will send those images to you.

So here's what we tried out and observed:
- The machine where this behavior occurs was setup 4 weeks ago and only Devart dotConnect 7.2.104 was installed ("only" stands for "no other versions of Devart DotConnect).
- After we uninstalled DotConnect and installed version 6.5.244 the problem was not reproducible anymore.
- But we need version 7.2.104 since we have some other issues otherwise.
- We tracked the application -> database activity with the dbMonitor and have taken screenshots of all important information.
- DbMonitor shows, that the "InValue" of the string parameter for the "Clob" column is valid (or at least looks valid) and the "OutValue" is invalid, containing "\0" after each character.

Is there a setting that we can change in order to make it work correctly? Do you have an idea what the problem could be caused by?

If you need any additional information, please let me know.

Andi

Please try the following:
1. Include "Unicode=true;" entry in your connection string.
2. Are you using OCI (via Oracle client) or Direct connection mode? Does the switch (OCI -> Direct or vice versa) help? Also specify the version of your Oracle client and its NLS_LANG setting from registry.
3. Specify your connection string (roughly, without credentials).
4. Do NLS_LANGUAGE, NLS_CHARACTERSET, and NLS_NCHAR_CHARACTERSET parameters of your Oracle servers (working vs faulty) differ?
5. Tell us the regional settings of your operating system where you are running the code: Control Panel > Reginal and Language Options > the "Standards and formats" drop-down value, Location, and Language for non-Unicode programs.

Please send us all available information about this issue via our contact form: http://www.devart.com/company/contact.html.

Hi Shalex,

thank you for your answer. I have sent all our collected information through the contact formular. Here the information regarding your question:
1. We tried out with Unicode=true, Unicode=false and without the Unicode-attribute. We observed the same behavior each time.
2. We use the direct connection mode. As far as I know we haven't tried out to connect via OCI. The Oracle client version is Oracle - Ora11203, NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252
3. Connectionstring: Server=localhost;Direct=True;Sid=SID;User Id=xxx;password=xxx;Persist Security Info=True
4. We tried it on different databases (located on different machines) and had the effect on both databases. If we access the same database from a different machine, everything works fine. NLS_Language is AMERICAN, NLS_CHARACTERSET is AL32UTF8, NLS_NCHAR_CHARACTERSET is AL16UTF16
5. Location: Switzerland, Language for non-Unicode program: German(Switzerland)

"Unfortunately" (good for us ) we can't reproduce the issue anymore. We got a new image for the target system and now everything works fine. So there is no urgency for this anymore. I hope the provided information can help you find the problem. The screenshots should be very helpful.

Best regards,
Andi

Thank you for the information you have provided. If the problem comes back, let us know.