|
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? |
See SAP KBA #1934022 for more information. 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?
(26 Nov '13, 14:23)
TonyV
Replies hidden
You need to deploy the 64-bit dblgen12.dll to match the application bitness, as I explained.
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.
(26 Nov '13, 14:38)
Jeff Albion
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?
(26 Nov '13, 15:03)
TonyV
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
(26 Nov '13, 16:12)
Jeff Albion
FYI, we switched the application back to 32 bit. We will revisit a 64 bit build at some later time and will make sure we use the 64 bit DLLs at that time.
(03 Jan '14, 12:07)
TonyV
|
