The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
Perhaps his illness has left him wringing his Hans due to a Darth of good ideas.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
Why upgrading MS-SSMS have to upgrade ODBC drivers? And why an admittedly compatible update can not be done without total remove of the previous version? And why the update rely on a previous (maybe totally foobar) install?
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
Why upgrading MS-SSMS have to upgrade ODBC drivers? It might depend on some extension available only in the new ODBC driver version. Or possibly the new version do not have new fuctions, but essential performance improvements. Or essential bugfixes.
And why an admittedly compatible update can not be done without total remove of the previous version? The currently installed version might be one of umpteen different ones, with all sorts of incompatibilities and other issues. Keeping a full catalog of all previous versions (in all regional variants, for all sorts of architectures, ...) telling which older modules can be kept and which must be replaced could be extremely difficult to maintain, and could make the install/upgrade procedures magnitudes more complex. Chances are that it wouldn't be much faster, either - simply showeling in the new version without asking any questions may be the fastest alternative, and certainly safest one. The installation package would have to include all modules anyway, just in case they were needed.
And why the update rely on a previous (maybe totally foobar) install? That could be for licensing reasons: An installed, older version proves that the user has provided a license for that install, so he doesn't need to present it again. (I've seen a few systems that were like that.) The installer might pick up license info from the old installation to incorporate into the new.
...Are you sure that you know what you really want? You seem to dislike that the update relies on a previous install, yet you seem to want it not to be removed (is that even if it is "totally foobar"?)
I know: Some software (often in huge program systems) do allow piecewise updates, leaving other, old modules untouched. This ususally requires a very strong programming discipline, where any change of module interfaces is a major architectural update. Some such systems also rely on every module being able to answer to requests from e.g. the installer about their version number, configuration etc. So it is possible, but it might require a lot of resources to maintain. For simpler systems, it may not be worth the effort. Besides, full replacement allows agile interface definitions, the way modern programmers expect them to be: Something that is defined by implementation, not by specification.