Definitely OT, but I do have an amusing DTS anecdote (it doesn't really consel specifically for Perl, but it's amusing nonetheless): one solution provider for our company had set up a database on a server kept in-house (with nothing else other than their software on it, fortunately). They created a DTS package to import data from our database each EOD.
Getting this vendor to do anything reasonable was difficult, but eventually we settled on a file format to pass to them and we passed it nightly.
For some reason, after a few weeks the server died. Wouldn't reboot, nothing, and we had to reinstall the OS. The server admins had no idea what happened, and chalked it up to chance.
That is, until it happened again after another few weeks. They replaced the server, agreeing with the vendor to chalk it up to a bad server.
Well, until it happened again a few weeks later, to the new server. Given the vendor's technical "expertise" evident in meetings, the server admins were getting suspicious (one might say they were a bit slow to get suspicious, actually). The put a monitor on the server -- and found that when the DTS package ran, somehow all the files in the Windows folder were being deleted and replaced a short time later. Examining the DTS package showed that they were using a DOS shell command to delete the import file (which they'd decided should go into the Windows folder) after processing. However, instead of using a command specific to the file, they were deleting everything. The OS would then replace the files automatically. At least, it would until it got fed up after several weeks of doing this daily.
Yes, the company (which I'm no longer working for) is still using the vendor. The vendor is extremely well-known in their field, and basically has no competition.
As for the question, I don't know enough about DTS packages, but I'd be surprised if there were anything particular they could do which Perl couldn't. It might be more a question of how convenient it is to do using Perl or DTS.
-----------------
s''limp';@p=split '!','n!h!p!';s,m,s,;$s=y;$c=slice @p1;so brutally;d;$n=reverse;$c=$s**$#p;print(''.$c^chop($n))while($c/=$#p)>=1;
| [reply] |
is there any point learning about and using MS SQL DTS when many of the tasks can be performed adequately using Perl.
It's always useful to know multiple ways to accomplish a task, esp, when so many solutions will be pre-created in another language for you.
There are a few things DTS, esp. in combination with the SQL Server Wizards, make easier. For one project, I have a DTS package that backs up my PROD DB to DEV, for testing and the like. Could I do it in Perl? Sure. But it was much easier to use the DTS-based Import/Export tool.
In general, I think it's best to learn as much as you can about a tool, and then see if using it fits your application/development focus. Obviously, you lose portability of code with DTS, and that's one major reason I shy away from its use, save with purely "backend" work like the DB backup mentioned above.
Learn DTS, learn Transact SQL, but also learn how to code well in Perl. The more you know, and the better you balance depth and breath of knowledge, the better your applications will be.
----Asim, known to some as Woodrow.
| [reply] |
I don't really think this should have been reaped. Maybe it should have been moved to Meditations or retitled to be something like "Perl vs DTS -- Can Perl Do It Better?"
To answer the question, IMHO no don't bother with DTS. Once I was forced to setup an application which used DTS to move data. It accomplished the same as hitting the DB with perl only it was more confusing. Better would have been if I had queried the DB with perl and written an xml or even a csv file and pushed it to the other machine.
OTOH, if you are a visual person and like the cheesy graphics and find the DTS interface easy to use, then by all means go for it. It is the MS way and I'm sure one day they'll make that the only way you can talk to MSSQL.
| [reply] |
