We have a couple applications that talks to our database engine through two different mechanisms. Our older applications use the ODBC driver and a C# wrapper, the newer ones use the ADO.NET driver. When testing with a db with a chinese codepage (GBK) strings are not being converted correctly using the ADO.NET driver, but the ODBC - C# wrapper programs show the chinese characters correctly. My suspicion is that the ADO NET driver has trouble finding the charset conversion tables? Also, if I install the SQL Anywhere deployment separately, then the ADO.NET character conversion works. Our deployment directories look like this:

The SA10 Engine files are deployed in <program files=""><Company>SQL Anywhere 10 (the win32, charsets and scripts directories). The ado.net assembly is deployed along with our programs in <program files=""><Company><Program Name> We have one directory for each program. We have usually 2 or 3 programs installed each under it's own directory, and each one has a copy of the iAnywhere assembly.

In summary, we are missing something that the regular SA 10 installation does, which enables the ADO.NET unicode conversion of characters stored in a non-latin codepage. I hope someone here can point us to what is wrong.

asked 17 Jan '12, 08:38

Sergio's gravatar image

Sergio
460151820
accept rate: 0%


We need access to dbicu*.dll for those conversions although, if they are not accessible, the conversion should be done at the server instead (I can't explain why that wouldn't be happening for you). I'm not an ADO.NET expert but I seem to recall the native DLLs in that package get unpacked into a temporary directory at runtime and then we may then have a tough time finding SQL Anywhere installation files since they are not in the same directory. With a full SA installation, we might have registry entries or the SQLANY10 environment variable to help us find the rest of SQL Anywhere.

permanent link

answered 17 Jan '12, 11:20

John%20Smirnios's gravatar image

John Smirnios
9.0k377114
accept rate: 39%

The problem is we can not rely on SQL Anywhere specific registry entries or path variables. If a user uninstalls SQL Anywhere 10 or installs a different, perhaps older version (for whatever reasons), it would break our software. Is there any alternative to have the ADO.NET driver working correctly? would it be enough to copy dbicu10.dll locally together in the directory where the ianywhere assembly lies? (We already do that for dblgen10.dll)

(18 Jan '12, 06:46) Sergio
Replies hidden

I'm not sure -- I was just trying to explain why there might be a difference in behaviour. You can try to copy the ICU DLLs into place as well (take note that there are two of them and the asa.cvf wouldn't hurt either though it is only used for SBCS-to-SBCS conversions). If you can't get it working, tech support may be the best approach or maybe someone else on this forum will provide a better answer. Also, you might use procmon (http://technet.microsoft.com/en-us/sysinternals/bb896645) to watch exactly where we search for the dbicu DLLs in the case where it is not working for you.

(18 Jan '12, 09:23) John Smirnios
1

Copying both dbicu* dlls to the same directory where the iAnywhere assembly lies solves the issue.

(18 Jan '12, 11:57) Sergio
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×114
×35
×12

question asked: 17 Jan '12, 08:38

question was seen: 1,320 times

last updated: 18 Jan '12, 11:57