April 24, 2025 at 2:59 pm
Upgrading an instance of SQL Server 2019 to SQL Server 2022 - I am so glad we're doing this in our test environment.
During the install, got a popup about a missing file C:\Windows\ProPatches\msoledbsql_18.7.4_x64.msi
Try again fails, obviously - I have no idea why they even have "try again" as an option, the file is either there or it isn't there. Hit cancel and it said that it would use an existing "valid" file that it found. Can anyone guess how that worked out?
The install seemed to continue but ultimately failed.
Found a fix in a bunch of different articles that you need to remove the ODBC and OLEDB drivers; the issue is apparently that the SQL installer is confused by their presence. Okay, fair enough - be nice if they'd document that somewhere or you know, just add it to the install process, but okay. Removed the drivers.
Tried to run it again, but it stops me because the instance MSSQLSERVER.INACTIVE is already using the ID... found an article here that tells how to get rid of that (thank you Nisarg Upadhyay if you're still around, great article)
Retried the upgrade and it seems to have worked - except that Replication failed to install/upgrade. It still seems to be working - I was able to create a new transactional replication, and it seems to be working. Still, glad this is a test box.
How in the heck does something like this get past QA? It's apparently been a thing since SQL 2019 and possibly even before. Why does the ENTIRE INSTALL bomb because it cannot update the OLE DB and/or ODBC drivers? And if they're that important, why aren't the part of the install rather than just hope that the right file is there?
Sorry, just had to rant at someone.
April 24, 2025 at 9:20 pm
How in the heck does something like this get past QA?
From what I've seen over the years with SPs, CUs, and new releases, I'm starting to thing that MS doesn't know how to even spell QA.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 30, 2025 at 8:52 am
I am retired now, but I always thought upgrading in place is a brave thing to do. Brave as in risky, too risky to do for a production instance.
I once did a scripted install of Windows and SQL to three new guest machines then did a scripted upgrade in place. Two worked, the third failed leaving SQL in an unusable state. It would not start, could not roll back to old version, and could not complete the upgrade.
In my old job I insited we always start with building a new Windows instance on a new guest server then do a clean install of SQL server on to it.
We used DNS aliases to link applications to servers, so after testing the new instance, cutover became a simple process of updating DNS (plus a 3 page checklist of everything else that needed to be done).
Best of luck with your upgrade in place. Review the issues you have had and decide if you want anything like that anywhere near your production instance. Then maybe recommend you use a new build as the key bit of your migration process.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply