|
Our environment is SA11, .net 4, using iAnywhere.data.SQLAnywhere.v4.0.dll. We have a problem with the generated file "dbdata11.dll". At runtime SA appears to generate the DLL named "dbdata11.dll" and write it to the windowstemp folder. A web app running with tight privilege control (e.g., as "Network Service") does not have privs to write to that folder. The .net provider fails (putting up a message box, even though there is no user, and thus the app hangs... but that's a story noted elsewhere.) We could run our web app under a different account, but we don't want to. We also found that if we place the dbdata11.dll into the same folder as the ianywhere dll, that copy will be used, so the write to the temp folder is not necessary. As it happens, the dbdata11.dll file is not installed with SA: the only way for us to get it is by running the app successfully, snagging the copy out of the temp folder, and henceforth deploying it with our app. We have to do this separately for 64 and 32 bit environments. So, a question: is it OK to grab this generated DLL and start distributing it? Does the DLL have any characteristics other than version and bitness that we should consider? One helpful thing that SA could do in the future is to make this dll available with the install. Other suggestions are welcomed. |
|
We don't want to install dbdata.dll separately. We bundle it on purpose so that there is no issues with missing files or mis-matched build numbers. It is OK to grab the generated DLL and start distributing it. The message box issue has been fixed long time ago. If the app doesn't have the privileges to write to the temp folder, the SA ADO.NET provider will throw an exception instead of showing a message box. ok, thanks. It's curious that this dll was singled out for special treatment since there are several others required by the .net provider: dbicu11.dll, dbicudt11.dll, and dblgen11.dll. But that's ok, I'm good to go.
(26 Feb '13, 17:16)
Leo Tohill
|
