Comments posted to this topic are about the item The Instance ID MSSQLSERVER Is Already In Use
Before following this tip, review the bootstrap folder and strive to determine why the upgrade failed. If you cannot determine why the upgrade failed, the advantage of reinstalling the operating system (over using msiexec /x) is that you have ensured all remnants of a failed and in-solvable upgrade are completely removed.
By following this tip you will not gain any assurance that you have a clean upgrade. It you 'must' follow this article because there are non-SQL Server processes installed on the same OS that also depend on SQL Server, by following this tip you may end up with new problems in those processes. And if you call MS Support with a new problem at any time in the future, and if they discover msiexec /x had been used to blast away an old version, you may end up hearing Supprt asking you to reinstall the OS.
In other words, msiexec /x is not supported by SQL Server Development or SQL Server Support, and the consequence of using it (such as abnormal product behavior) is also not supportable.
Caveat emptor. It is far better to flatten the box, IMO...
great - if I ever run into this error and I only have a small maintenance window for a physical machine I will give it a try. Reinstalling the OS, SQL Server and attaching hundrets of DBs would take too long.
I would always prefer a clean SQL installation instead of doing an upgrade, but there are situations, where you have to do what needs to be done.
Thanks for sharing this fix
gerald72 - Wednesday, September 27, 2017 11:39 PM
I have a development SQL Server with 500 databases that serves 200 users (including ~100 developers, many of whom work odd hours). I log ship to a secondary, because I want to be prepared for the many ways a setup, the OS, or the hardware can fail :). For my production servers I harness clustering, which allows me to rebuild a server outside of a maintenance window.
SoHelpMeCodd - Thursday, September 28, 2017 7:08 AM
Same here (besides alwayson ags) - but I wasn't sure if this problem also could apply to named instances. But if it does (and I'm nearly sure it could also haooe there) we are safe.
Viewing 5 posts - 1 through 4 (of 4 total)