- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
As somebody already stated:
The WTF is not using a decent testing environment. That means a duplicate of your production environment. Double the price, double the effort, but less mistakes.
The loss in value of losing a production database-server is much more than the price of a testing environment. Everybody knows that. But they want to take the risk.
Having a safety net underneath your critical tasks makes you sweat less and concentrate better.
After tested the whole procedure of patches /service packs, you can print a test result to the deployment department and demand these procedures to be executed.
What is so difficult? Trying to convince the managers involved.... But that's always a first class WTF.
Admin
This is a known problem with the original version of SQL Server SP2. The problem is in the updated admin tool (not the server software). It corrupts the cleanup interval of SQL Server 2005 maintenance plans when they are edited. This does not apply to the current version of the patch available since March 05, 2007, and there is a GDR patch which should be applied to all machines running the admin tools which were patched with the original SP2.
See http://support.microsoft.com/kb/933508/en-us for details.
On an aside I do apply service packs - but unless they fix a problem I have, I have been known to wait before doing it. Still actually don't have SQL Server SP2 on my machine - but it is always behind NAT firewalls and clients are not on SP2 yet either.
Admin
Thanks for that salutary tale, Daily What The Just So Stories! Tomorrow, can we have the one about the little coder who wouldn't write unit tests?
Admin
Wait, I think I used to work for this company. I used to work for a company that didn't like patches being installed.
Claimed exactly this reason too....patches would break it.
Though to be fair, I did release a beta (of a commercial application) once that did break once the patch I submitted for glibc was released into the wild. But, to get the beta out the door, I had to make it work with the bug....and it wasn't really my fault that the tester waited 6 months before finally trying to run it.
I also remember the days where software was only supported on the exact version of some dependent application or operating system....a full QA test cycle was required each time something major got patched.... And, SQL server was one of the dependent apps....though IIS and iPlanet were also big. It took worms that exploited IIS and SQL server to change that thinking.
The office had gotten shutdown for days due to worms affecting Windows vulnerability (though my machine always made it through, because I kept it patched).....then it became mandatory to update daily, etc.
Odd how I miss those days....
Admin
<whisper>Don't worry. I work for Microsoft [snicker]</whisper>
Admin
Well there are a series of numbers that MS either blacklisted as stolen or their hash values came out to something similar or something, the details are not really known to me. This made some perfectly legit serial numbers show up as bad. MS has since updated their serial generation to not print numbers that fall into that category, but this does nothing for those people with legitimately purchased copies that are giving a false reason of being stolen simply because they purchased to early before the number check got put in place.
Admin
I would have agreed, had I not just started working with someone who was EXACTLY like this...
"Service packs are inherently dangerous; problems might arise!" - is just the kind of thing he would say...
and this from the same guy who pulled the wrong drive in a two disk array when the other one had failed .
Admin
A SQL Server Patch and Service Pack are two entirely differnt animals. In the past SQL Server Service pack have caused problems. That really doesn't happen anymore. The only problem I know recently was SQL 2000 SP4 for 64 bit machines. The problem was all over the blogs and SQL Service packs revert gracefully.
You are by far better of installing them on SQL Server than not.
Admin
Admin
Or to InnoSetup, also works, also open source.
Admin
Admin
Happy like kids to the thought we might finally be able to try our new 4-core computer, we register online, but bam, database error. Naively, we retry but the number is no longuer allowed. We call and end up after 10 minute on some hungarian who hangs up on us as soon as we say "activate".
..and as for today, we're still trying to activate that ****.
Admin
This is why you validate patches on an isolated system before deploying.
Admin
The simple reason for keeping your production servers current on service packs is that your developers will! It is always best to develop against a fully patched system to head off any problems that might be caused by additional security features or to benefit from additional functionality. So the net effect is that the code goes into QA and it breaks and the developers say "install the latest service pack". If QA says (rightly) that they won't until it is install on production, the tell them you'll happily wait on any new builds until they do. Installing a service pack is FAR less expensive than having developers hack around the fact that it is not installed. You don't have to be upto the day, but IMO you shouldn't let it go more than a couple of months.
Admin
Happy ending! Rock on!
Admin
We had a client install an update to SQL Server a few years ago (SP2 to SP3 for some SQL Server version) and it most certainly did break things.
And not in some easy to fix way, either. It broke the application inside some java library from a third party which meant that the application did not work at all.
Admin
You people want a WTF? How about this one: windows administrators are per default administrators on all databases in a SQLServer.
So... The guy who build / maintains the building of a bank also has full access to its vault. Microsoft logic. Hence the $ instead of s, I guess.
Admin
I agree but he does have a point - the real culprit here is the law of averages. A person is smart - people as a collective are usually stupid. Going from one extreme to the other is not a solution and I can plainly see the end results of this story were not the real goal of the person who started the complaints in the first place. The real solution would be to have a sanity check before applying the patch to a production environment - staging anyone? (but you know how some people in power are - to them it is usually a black and white issue - get a bunch of them in a room together and watch the fires start ablazin) - the end result of this story sadly usually flies in an environment where there are too many cooks that cannot smell the shit burning are in the kitchen, which always results in the same outcome, people get burned. In my experience the larger the corporation - the more ignorant and slower the environment.