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
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.
answered 17 Jan '12, 11:20