We install SQL Anywhere in a custom manner together with our software. SQL Anywhere gets installed under our applications main directory instead of directly on "Program Files\SQL Anywhere 10", but other than that, the folder and file structure remain the same. Yesterday when testing our deployment, we got the error message that dblgen10.dll cannot be found. The easy solution would be to copy the dblgen10 file in the same directory as our application executable, but i really don't want to do that. If i use a generated SA10 Deploy, the issue goes away. So the question is, what does the SA10 deployment do that our custom deployment is not doing? Are there any registry entries or other variables being set? The custom installation is done to avoid conflicts if our customers install other versions of SA10 on their own, so we cannot rely on the %SQLANY10% variable.
asked 29 Jun '10, 17:01
SQL Anywhere looks in a number of places in its attempt to find the language resource file - the exact list of places (and order) vary slightly for each version, but the list is basically the following (from the 10.0.1 source):
The above applies for Windows. There are a few other places that are searched on the Unix platforms.
So in your case, the difference may be the existence of the registry setting? ... But provided that dblgen.dll is in the same directory as the .Net library I would have thought that the first location (same dir as module) would have found it? I.e. your application should not need to set any registry settings in order for it to work.
answered 29 Jun '10, 19:56
For Windows systems, the difference may be the PATH environment variable, which is set by default to the SQL Anywhere binary directory, i.e. %SQLANY10%\win32 for SA 10 32 bit or to %SQLANY11%\bin32 for SA 11 32 bit.
answered 29 Jun '10, 19:35