Recently, we carried out an upgrade and installed a patch for a client’s SQL Anywhere software.
The server has Windows Server 2008 R2 SP1 and IIS 7.5
Upon the server being restarted, after the upgrade and install of the patch, we were able to access the database through a Windows Forms application, but were not able to make a connection through our Web application. Our Web application has a C#/ASP.NET from end and the application was recompiled with the new dll (iAnywhere.Data.SQLAnywhere.v4.0.dll) from the upgrade.
We could not replicate this issue on our development server and so could not see the details of the error or any exception that may have been thrown.
After endless attempts to get the Web application working it was decided to uninstall Sybase and reinstall the original version (126.96.36.19942), that was previously working. We were still unable to make a connection to the database through the web application at his point. The server was rolled back to a snapshot before the initial SQL Anywhere upgrade and patch install, where the application runs as expected again.
My questions are:
asked 01 Oct '13, 15:42
Are you installing the 'full' SQL Anywhere software here, or are you just installing a deployment of SQL Anywhere?
The original .NET Framework version of the SQL Anywhere assembly is v2.0 (the build number is '188.8.131.524' - the extra '2' denotes ".NET Framework 2.0"), but you're referring to the .NET Framework 4.0 DLL in your question. Are you also upgrading your ASP.NET application from .NET Framework 2.0 to 4.0?
Not with specifically installing and accessing the ADO.NET provider, no - I would assume this is a configuration issue on the production machine.
No, although how you configure the IIS server and deploy the provider files can make a huge difference in how the provider files are referenced. Were any files possibly in use when you performed these upgrade steps, or was everything shut down first?
The ADO.NET provider is composed of both a managed (CLR Asssembly) and an unmanaged (DLL) file. During runtime, we extract the unmanaged component to the system temporary directory from the managed assembly resource. From that extracted unmanaged component, we will then need to locate the native DLL files 'dblgen11.dll' (English-language), and optionally 'dbcon11.dll' in the native file system path. (as mentioned here)
See this question for a discussion about how we reference the native DLLs in an IIS setting for an ASP.NET application - you will likely want to ensure they can be located in the
General ASP.NET error-handling techniques should be able to tell you more about what's happening here - specifically putting the operations in a
How are you referring to the SQL Anywhere ADO.NET provider in your code? Are you creating
You can also try re-running the .NET Assembly setup from the Assembly folder to ensure everything is registered correctly with the Global Assembly Cache (GAC):
%SQLANY11%\Assembly\v2\SetupVSPackage /i %SQLANY11%\Assembly\v4\SetupVSPackage /i
Finally, you will also want to be aware of any
answered 01 Oct '13, 17:31