Cobb: DTS Bitching

April 04, 2005

DTS Bitching

I don't know whether to piss and moan because I have been forced to use DTS or be glad that I'm learning it. Hmm. I guess I'll just bitch. It turns out that DTS has a very clever trick. You see its scheduler only runs the versions of the DTS package that you created it with. Sensible, but counter-intuitive.

So imagine that you inherit a pile of spaghetti in which the production stream is, for some unknown reason, stretched across two machines. So half of the production run goes on one DTS package which then FTPs data over to another SQL Server and which then runs another set of DTS packages. You find a silly glitch in one of the packages, correct it, save it and you're good to go right? No. You have to disable the calling job and recreate a new job.

Of course there's no way to tell this unless logging is enabled. Is it? Hell no. So when I enable logging, I get some godawful hashed names. Well, I shouldn't be so harsh because I like hashed names, but we all know the Microsoft hashed GUIDs don't use a real secure hash. But I'll play Monty Hall and give a big blog shout out for whomever can show me the MS Hash algorithm.

And what's the deal with the internal names in the text logs? What do I care about DTSTask_DataPumpTask_43? Why do you think I put human readable text in the description box, maybe so I could read the log? Duh! I still haven't figured out why parameter passing doesn't work like it should. Something tells me that the scoping rules won't work either. And don't even get me started on notifications and operators.

Why did it take me a week to figure this out? Because there's no test environment of course. We just slam everything into production. Now you know I shave my head, there'd be too much grey.

Posted by mbowen at April 4, 2005 06:14 PM

Trackback Pings

TrackBack URL for this entry:
http://www.visioncircle.org/mt/mt-tb.cgi/3567