Recently, we carried out an upgrade and installed a patch for a client’s SQL Anywhere software.

  • Original version of SQL Anywhere 11.0.0.12642
  • Upgrade SQL Anywhere 11.0.0 to 11.0.1
  • Patch Installed 11.0.1.2960

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 (11.0.0.12642), 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:

  1. Are there any know issues with these versions of SQL Anywhere and the software on the server?
  2. Or any other known issue with this upgrade?
  3. Is there anywhere on the server I can look for the details of the error/exception that may have been thrown to better research this issue?

Thank you

asked 01 Oct '13, 15:42

MARivera's gravatar image

MARivera
31113
accept rate: 0%


carried out an upgrade and installed a patch for a client’s SQL Anywhere software.

Are you installing the 'full' SQL Anywhere software here, or are you just installing a deployment of SQL Anywhere?

reinstall the original version (11.0.0.12642) ... the application was recompiled with the new dll (iAnywhere.Data.SQLAnywhere.v4.0.dll) from the upgrade.

The original .NET Framework version of the SQL Anywhere assembly is v2.0 (the build number is '11.0.0.1264' - 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?

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. Are there any know issues with these versions of SQL Anywhere and the software on the server?

Not with specifically installing and accessing the ADO.NET provider, no - I would assume this is a configuration issue on the production machine.

Or any other known issue with this upgrade?

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 C:\Windows\System32\Inetsrv folder, if the files aren't already considered in the system %PATH%.

Is there anywhere on the server I can look for the details of the error/exception that may have been thrown to better research this issue?

General ASP.NET error-handling techniques should be able to tell you more about what's happening here - specifically putting the operations in a try ... catch might be helpful. See: http://msdn.microsoft.com/en-us/library/ms165012.aspx


How are you referring to the SQL Anywhere ADO.NET provider in your code? Are you creating SAConnection objects directly, or are you using a DBProviderFactory? If you're using a DBProviderFactory, you may also need to check the registration of the provider in the machine.config file of the Framework version you're running and this determines how the assembly is located.

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 policy.* assemblies that are installed to the GAC after you finish the upgrade - these policy files perform a binding redirect to the version and build of the assembly of the same version and build that the policy was created with - if your application is expecting a certain version of the assembly from the build environment and is finding another version at runtime, .NET will throw an exception in this case.

permanent link

answered 01 Oct '13, 17:31

Jeff%20Albion's gravatar image

Jeff Albion
10.8k171175
accept rate: 25%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×159
×90
×62
×4

question asked: 01 Oct '13, 15:42

question was seen: 7,360 times

last updated: 28 Jul '17, 07:20