|
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. |
|
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. 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
|
