I use maintenance plans. But my pet peeve is any software that, when something breaks, provides little in the way of meaningful feedback about the cause. (As an aside, my experience with web developers as a species is their absolute refusal to include conditional displays of the commands they're sending to the database -- too much of my time is spent looking at their code and trying to intuit the actual command being sent in.)
DTS is rife with this flaw: Nine out of ten failures yield "Error 22029: The step failed." Yeah, like, "No shinola, Sherlock!" How hard would it have been for the developers to have found a way to inform the user (me, in this case) the source of the actual problem? It *knows* what the problem is, it just won't tell me.
The benefits of maintenance plans, in my mind, outweigh the irritations. But it would be better if the jobs they spawned would specify any problems they encountered. As for DTS, I don't bother with making my own packages. If something breaks, I like to know where to start fixing things.
Black boxes are fine for things that always work, which is precisely why I despise wizards: They don't always work. Sometimes, they don't even "most often" work. Just last month, I wandered into a disaster during what should have been a routine upgrade from SQL Server 7 to 2000. Point --> click, what could be easier? Only problem is, the wizard broke and henceforth resisted all of my efforts to cajole it to function correctly. (I never did discover why it broke; if the wizard knew, it wasn't sharing that knowledge with me.) At least, with a checklist and a command line, as inconvenient and error-prone as that is, you are the pilot. When a wizard is doing the work, you are the passenger, and when the wizard begins steering for the side of a mountain at full speed, all you can do is scream.
Edited by - Lee Dise on 04/11/2002 07:13:24 AM
Edited by - Lee Dise on 04/11/2002 07:42:42 AM