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.