Hello Bharat,
The ADO.NET provider is a combination of managed and unmanaged components. Inside the managed 'iAnywhere.Data.SQLAnywhere.v3.5.dll', there is an unmanaged 'dbdata12.dll' component that will be extracted and referenced during runtime. This unmanaged component dll will try to reference the 'dblgen12.dll' in order to load language-specific error messages. The way an unmanged DLL is loaded by a program (in this case, another unmanaged dll) is governed by the following methods in Microsoft Windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
Depending on how your .NET project is being launched, different strategies may be used to reference the dblgen12.dll:
- The current working directory of the .NET program
- The %PATH% environment variable
- If running an ASP.NET program on IIS, '
C:\Windows\System32\Inetsrv' is used as the 'current working directory' for the .NET program to reference unmanaged DLLs
Alternatively, you can specifiy an explicit path to add to the %PATH% variable, prior to referencing the SQL Anywhere ADO.NET Provider components, and then put the DLL file there:
System.Environment.SetEnvironmentVariable("Path", searchPath +";"+ oldPath)
---
A reminder that the bitness (x86 or x64) of the .NET CLR will be the bitness you need to match with the dblgen12.dll file. If your program is compiled for 'Any CPU', it will use the 32-bit DLL on 32-bit systems, and 64-bit DLL on 64-bit systems. If it's compiled for 'x86', it will always use the 32-bit DLL on all systems, and if compiled for 'x64', it will only reference the 64-bit DLL on 64-bit systems.
Regards,
Jeff Albion
SAP Active Global Support
