on 2013 Nov 26 12:07 PM
We're running SQL Anywhere as an embedded database in our application. Our installer copies SQL Anywhere in the ../sa folder under our application's folder in Program Files (x86) on Vista & Higher machines.
We're getting ready to release a new version next week and we're engaged in final testing. One of our test machines started generating the following error:
Cannot find the language resource file (dblgen12.dll).
I did a search of the hard drive on that machine and dblgen12.dll exists in the ../sa/BIN32 folder, where I'd expect it to be. There are no other copies anywhere on the disk.
What causes this error and how do we fix it?
Request clarification before answering.
The language file must be located on the application's %PATH%
or located relative to the application. For a list of locations we search, see: http://dcx.sybase.com/index.html#1201/en/dbadmin/da-install-s-5107108.html. There are also other referenced DLLs that must be present.
The DLL file deployed must match the application's bitness. For .NET applications, compiling with "csc /platform
" to specify x86 (32-bit), x64 (64-bit) or 'Any CPU' (default: 64-bit on x64 OSes, 32-bit on x86 OSes) will determine which bitness of the Common Language Runtime (CLR) is loaded at run time. You must match the bitness of the DLLs to the CLR loaded.
ASP.NET applications are slightly more special in their deployment requirements - see this question.
See SAP KBA #1934022 for more information.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Jeff: Our application is now compiled for 64 bit. We're running the 32 bit dbsrv12.exe. dblgen12.dll is in the same folder as dbsrv12.exe. Our app has never had a problem with this DLL before. Are you saying that we should be running the 64 bit server with the 64 bit application? Even though the server is running in its own process as a service?
Our application is now compiled for 64 bit.
You need to deploy the 64-bit dblgen12.dll to match the application bitness, as I explained.
Are you saying that we should be running the 64 bit server with the 64 bit application?
No - the deployment of the database server is okay (although if you're running an x64 OS, we'd highly recommend to also run the 64-bit database server to make the use of the maximum amount of memory on the system).
I'm suggesting that if your application is 64-bit, you need to deploy 64-bit client DLL libraries to match the application (so not in "bin32", but in "bin64"). The 64-bit database client can communicate with a 32-bit database server without issue.
Jeff: OK, I understand that. Previously, our application was 32 bit and we deployed SA in the ./sa/BIN32 folder, as I've said. How is it that everything worked for the 32 bit application? According to what I've read, the application should never have found the dblgen12.dll, as it wasn't in ./BIN32 but ./sa/BIN32. Or am I missing something?
If your original application is 32-bit, and you deployed the 32-bit DLLs, everything would be okay. Since switching to a 64-bit .NET application, you need to switch to the 64-bit DLLs also.
As for the switch between "./bin32" to "./sa/bin32", I can only imagine that the 'current path' for the original application must include the "./sa" folder in the directory list, otherwise the native DLLs would not be located.
You can always check the 'Environment' tab for a process inside Process Explorer to check what the current PATH
is set to.
User | Count |
---|---|
50 | |
9 | |
8 | |
6 | |
5 | |
5 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.