
Upgrading from GP 2015 (latest update) to GP 2016R2 (downloaded yesterday). Did all the prerequisites. Installation finished without errors. Ran GP 2016 Utilities to upgrade SQL 2014 database and received the following errors before it exited incomplete:
Error: The following SQL statement produced an error: EXEC wfDeployClrAssemblies
ERROR [Microsoft][SQL Server Native Client 11.0][SQL Server]Failed to create AppDomain "master.dbo[ddl].2". Exception has been thrown by the target of an invocation
Put in a service request with Microsoft, but may not get an answer until Jan 3.
Any suggestions on a fix?
*This post is locked for comments
I have the same question (0)Hello Mike,
You may've already resolved this, but if not, I wanted to mention....
This “Failed to create AppDomain” error is normally caused by, but not limited to, having a x86 (32-bit) version of Microsoft SQL Server, that you're launching Utilities against.
The issue is due to VAS limitations, whereas we don't normally see this with a x64-bit version of SQL. What the issue amounts to is that SQL is using or doesn't have, enough memory in order to process the procedure, thus the error message being shown. Unfortunately, in most cases, it doesn't have anything to do with the amount of physical memory that you have on the SQL Server, but more so how SQL actually uses that memory.
The only work-around we've found, which you also have done, is by stopping and restarting the SQL Server service, which drops connections and frees up resources, then launching Utilities again, which usually gets past the error message(s), which you also have seen.
However, eventually, as the resources and connections are made in SQL again, it will show this error again and again, which is why we would recommend going to a x64-bit version of Microsoft SQL Server, as a 'fix' for this type of issue.
Again, it doesn't have anything to do with the amount of total or available RAM that you have on the SQL Server itself, but more how SQL Server uses the memory and virtual memory in its processing. We don't have any configuration for SQL Server that would optimize how SQL uses the memory resources, but again we've seen this more commonly on 32-bit versions of SQL Server, compared to 64-bit versions.
You can confirm your version of SQL by running this script: Select @@Version
Thanks,