Bad Programming
-
On the heels of the Maintenance Cleanup Task fiasco, and then still another maintenance plan bug, I was very surprised to see this KB article. This one exposes your passwords in a log if there is any issue with the backup command. I know that the backup command rarely fails, at least I've almost never had issues, but I do know that writing out passwords in any log file is a bad idea.
I've banged on Microsoft a bit lately, but I still think that they have turned out terrific products. Every version of SQL Server I've used, now 7 and counting, has been better and better. The team developing SQL Server has done an amazing job with SQL Server 2005 and they should be incredibly proud.
However these types of programming mistakes are just examples of poor development practices. A password shouldn't be logged ever. Even if you make use of error logging routines developed by someone else, passwords can't be exposed. This just gives people another place to attack your systems. Or your backup tapes.
Regression testing of code is critically important. All of your architecture, development, and inital code decisions can be thrown out when a change is made to code, so the testing is very, very, very, (repeat this a few more times), very important.
Microsoft has a tough job and I can appreciate that. It's hard to cover so many possibilities of server hardware, configurations, and who knows what else. However these aren't obscure setups. At least the maintenance tasks are run daily in a common way.
As long as the cycle was for Service Pack 2, it seems that there still wasn't enough work done. To me this highlights what I've asked for in the past. Give us smaller, more regular service packs that contain just those fixes that have completed testing.
And NO new features.
-
I just wanted to point out that by reading your article I understood you were talking about an sql 2005 sp2 issue, but according to kb 913789 it is an sql 2000 problem. Maybe it's just me, but I think the article is a bit confusing on this.
-
Bad grammar! That should read 'on the heels'.
-
I agree with jc, the kb is about sql 2000 and I thought you were saying 2005 has the password log bug.
On Microsoft testing in general, it can be good sometimes but at others it is clearly lacking. As an example, I have done a lot of work with Microsoft Content Managment Server (MCMS). MCMS allows either sql or windows authentication to the database. Service Pack 2 for MCMS was released with a bug that forced you to allow windows authentication to work even when you were using sql authentication. The fact that such a bug could slip through says to me that Microsoft only test default configurations and really don't explore all the options. A hotfix had to be quickly released to resolve the issue but it was a poor showing of testing for a good product.
Craig
-
Please alow me to refer to the sp2a thread for followup of sp2 :
http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=112&messageid=349577
Johan
Learn to play, play to learn !Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:- How to post Performance Problems
- How to post data/code to get the best help[/url]- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
-
I would really really like a standard schedule for releasing Service Packs. This allows workload to be predicted and planned. Irregular SP releases mean irregular application of SPs. If the work schedule for the current year is full, the SP implementation won't happen until next year, regardless of what the SP contains!
Looking at a different vendor, IBM has a standard cycle for DB2 fix packs. My understanding is that IBM have dedicated teams building and testing fix packs, leaving the main DB2 development team doing what they do best. Maybe Microsoft needs this separation of staff, so that test professionals can focus in getting the quality of Service Packs improved, and the SQL authors can focus on the next SQL release.
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
-
My only problem with more and smaller service packs is that all I will be doing is implementing service packs OR have a handful of SQL Servers that are so behind of SP's that MSFT won't support me when I call. We have over 20 production SQL Servers running here and we are running mostly bundled software packages. We are dependent on the software companies to certify versions and SP's of SQL Server so I am at the mercy of them. We just purchased a new application and they still don't support SQL 2005, only 2000 SP3a and SP4.
-
I agree with Ed about the standard schedule for service pack releases. Just keep them down to a small number per year. The number 1 seems ideal to me, assuming the SP doesn't break a lot of working databases and makes the release of a second, third and forth SP to fix the first one a requirement:-)
-
Maybe one reason vendor applications do not support the latest service pack is they have their own work schedules. Adjusting the schedule to fit in a SP just because Microsoft have finally decided to release one is difficult. If SPs came out on a predictable schedule, vendors would be able to plan for them...
Another reason why vendors may be late in supporting SPs is their customers let them get away with poor behaviour. How much pressure have your management put on your vendor account manager to get the product updated?
It would be good to hear from application vendors their views on why support of SPs is often very late.
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
-
The new KB article is for 2000 and I should have called that out, though I think it's still a bad programming problem.
I agree with Ed that regular SPs would allow vendors to certify quickly. I'm sure that some vendors got the SP2 beta back in August and were working on it, but it's now six months later. Their priorities would have shifted to other work and waiting for the SP to release. Others are just plain lazy and don't want to spend the resources for certification. They'd rather devote resources to new versions, make you upgrade, and then gather revenue for a current product.
-
To the backup 'bug'. I just had 3 failures in backups last night coincedentally. So I checked out the event log per the KB. Well, no userid or password was found. This was on 2 SQL Servers, one 'standard' and one 'enterprise' - a cluster. Both are SQL 2000 with SP3a and hotfix 818. Both servers are using the SQL Agent with Windows authenntication running on Win 2K3 Sp1 'standard' and 'enterprise' respectively. So it seems MS still has a bit more vetting/testing of this KB that has been published in order to clarify the conditions when it occurs.
As for the SP scheduling, well, Sybase has had a reasonable publication schedule of 'fixes' (EBS/SWR/etc) for some time now. Granted this is a SQL Server site, but maybe MS can learn something from a competitor and better themselves from the experience !
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
Maybe it is my interpretation but this kb bug fix is only for backup jobs that are password protected. Not standard backups..... again, maybe it is just the way I am reading it.
-
It's all in the numbers
If MS were to release a new, smaller service pack once every quarter (for example) they would be at Service Pack 8 by the end of the second year, Service Pack 12 at the end of year 3, and up to Service Pack 20 by the time the product is ready to enter extended support (this assumes I read the support guidelines properly). I think the thought of "Service Pack 20" probably doesn't sit to well with their marketing folks OTOH, a lot of DBA's refuse (and with good reason) to install "Hot Fixes" on a one-off basis. Maybe a compromise would be in order, where MS could regression-test Hot Fixes and package them up in small packages on a regular basis between Service Packs? MS should consider putting several thoroughly regression-tested hot fixes in smaller regularly distributed packages, and then convincing DBA's that these hot fix roll-ups won't break their systems.
-
That all sounds good, however, we have alot of software package companies that I want to apply a SP or hotfix to and they tell me frankly, you apply that and you are no longer supported. So, my hands are tied unless I have an emergency show stopper problem like Slammer.....
-
I am not trying to defend Microsoft. I used to work for a software development company, when the company announced the software released date, and you knew it was not ready, you still had to ship the software and put out a patch immediately.
It is good to put out a schedule for the patches but there are customers screaming for those patches, so they just have to release when it became available.
I used to work with Oracle and Oracle ERP system. The patches came out everyday and you could not even keep track of it. We need to hire a DBA for Oracle database and an application DBA for the ERP system.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply