I successfully upgraded a dev copy of a site from 7.6.0 to 7.11.1, made some code updates (due to the change in how picker properties are stored), and tested.
After that, I completed a dry run on our staging server, with no issues.
Finally, today, we attempted to go live with the upgrade. The installer failed, and we unfortunately had to revert. Here is what we found in the UmbracoTraceLog:
2018-08-15 19:43:14,254 [P5864/D2/T16] ERROR Umbraco.Web.Install.Controllers.InstallApiController - Installation step DatabaseUpgrade failed.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Umbraco.Web.Install.InstallException: The database failed to upgrade. ERROR: The database configuration failed with the following message: This SqlTransaction has completed; it is no longer usable.
Please check log file for additional information (can be found in '/App_Data/Logs/UmbracoTraceLog.txt')
at Umbraco.Web.Install.InstallSteps.DatabaseUpgradeStep.Execute(Object model)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Umbraco.Web.Install.Controllers.InstallApiController.ExecuteStep(InstallSetupStep step, JToken instruction)
The only difference is that our staging database is on a VM, and our production database is an Azure SQL database. The login on Azure has not been restricted in any way, and should have all the necessary permissions. Is this a time out error? If so, is there a way to manually run the database migrations directly within SSMS? Any other ideas?
Well, I think we've got it fixed now. Here's what we did:
Created a copy of the production database.
Pointed local dev to the copy, and cleared out the App_Data folder.
Ran local dev, and completed the installation.
The above steps reproduced the error locally, without all the noise in the log file. I was able to determine that there was a time out error in the logs prior to the above exception/stack trace.
Increased the Connection Timeout in the connection string.
Re-ran the installation, and the installation completed successfully.
We were then able to apply this to production, and the upgrade completed successfully there as well.
Upgrading 7.6.0 to 7.11.1
I successfully upgraded a dev copy of a site from 7.6.0 to 7.11.1, made some code updates (due to the change in how picker properties are stored), and tested.
After that, I completed a dry run on our staging server, with no issues.
Finally, today, we attempted to go live with the upgrade. The installer failed, and we unfortunately had to revert. Here is what we found in the UmbracoTraceLog:
2018-08-15 19:43:14,254 [P5864/D2/T16] ERROR Umbraco.Web.Install.Controllers.InstallApiController - Installation step DatabaseUpgrade failed. System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Umbraco.Web.Install.InstallException: The database failed to upgrade. ERROR: The database configuration failed with the following message: This SqlTransaction has completed; it is no longer usable. Please check log file for additional information (can be found in '/App_Data/Logs/UmbracoTraceLog.txt') at Umbraco.Web.Install.InstallSteps.DatabaseUpgradeStep.Execute(Object model) --- End of inner exception stack trace --- at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at Umbraco.Web.Install.Controllers.InstallApiController.ExecuteStep(InstallSetupStep step, JToken instruction)
The only difference is that our staging database is on a VM, and our production database is an Azure SQL database. The login on Azure has not been restricted in any way, and should have all the necessary permissions. Is this a time out error? If so, is there a way to manually run the database migrations directly within SSMS? Any other ideas?
Well, I think we've got it fixed now. Here's what we did:
The above steps reproduced the error locally, without all the noise in the log file. I was able to determine that there was a time out error in the logs prior to the above exception/stack trace.
We were then able to apply this to production, and the upgrade completed successfully there as well.
is working on a reply...