Custom Ado.net deployment problem in SQL Anywhere 10

[Former Member]

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.

[MarkCulp]

If you didn't put dblgen10 in the same directory as your executable, where did you put it?

[MarkCulp]

I guess I should have first asked: Which application is giving the error? Your application or the database server? Then to answer my first question, it sounds like your structure is Program Files<your app name>SQL Anywhere 10<SA-files-and-dirs>... - is this correct?

[Former Member]

Hi Mark, that is correct.

[Former Member]

The SQL Anywhere deployment is in Program Files<Company Name>SQL Anywhere 10<SA-files.and-dirs>. And the application that uses it copies the iAnywhere.Data.SQLAnywhere10.dll locally, and lies in the following directory: Program Files<Company Name><App Name>\\

[MarkCulp]

Ah, so there is the issue... because SA's ado.net driver is copied to the app directory, the search for dblgen.dll in "the same directory as the current module" fails to find the file.

[MarkCulp · Accepted solution]

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):

• same directory as the current module that is looking for it (e.g. dbodbc.dll)
• same directory as the executable (e.g. your application exe)
• the current working directory
• the %SYBASE (environment variable value) directory, if set
• the 'win32' directory beside the directory of the current module
• the 'win32' directory beside the directory of the executable
• the directory specified in the [HKCU|HKLM]\\Software\\Sybase\\SQL Anywhere\\10.0\\Location registry keys
• the Windows directory
• the Windows system directory
• any directory listed in the %PATH environment variable
• the %ASANY[10] (env var value) directory, if set

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.

[Former Member · Accepted solution]

It seems that the only easy way to solve this is to just copy the dblgen10.dll to the application directory. Thanks for the answer!

[VolkerBarth]

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.