I created a DTS package in a test environment to update one database from another located on another server. I gave my DBA a heads-up because I wanted him to check it out before moving it into production, and he wasn't sure why I had used a DTS package to begin with. Are there disadvantages to using DTS for such updates?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
DTS vs Scheduled Jobs
- Thread starter eao
- Start date
- Thread starter
- #3
A scheduled DTS is a job - tell him to look in EM under management SQL Server Agent - jobs. In there will be scheduled DTS packages.
Job security may well be the motivation here.
Ask him to explain why its not an appropriate choice - and why his method is !
![[bandito]](/data/assets/smilies/bandito.gif "[bandito] [bandito]")
[blue]DBomrrsm[/blue]
[blue]Software code, like laws and sausages, should never be examined in production[/blue][black] - [/black][purple]Edward Tenner[/purple]
Job security may well be the motivation here.
Ask him to explain why its not an appropriate choice - and why his method is !
[blue]DBomrrsm[/blue] [blue]Software code, like laws and sausages, should never be examined in production[/blue][black] - [/black][purple]Edward Tenner[/purple]
eao,
Don't be so quick to condemn your DBA.
How complicated is the database update? If it is a very simple update without a whole lot of data massaging taking place, then using only a Job may be appropriate. Using the principle of KISS, why involve both a DTS package and a scheduled job if you can accomplish the task by using only a Job?
On the other hand (and this is something I have not had personal experience with, so I am only speculating), I have seen that error messages from a SQL Agent Job (at least when running a DTS package) are not very helpful. In the ease of maintenance category, I would have to say DTS (at least in my experience) leave the SQL Agent Job in the dust.
And, maybe it's just that your DBA does not have experience with DTS and doesn't know its capabilities.
Is it really worth it to butt heads with your DBA? For now I would say that if you can do the update with only a SQL Agent Job, go with that. Later, if a problem arises which DTS could take care of, point this out (in a helpful, friendly way) to your DBA. Also, make a case for DTS vs. SQL Agent Job and present it to your DBA. Cooperation works a whole lot better than confrontation.
Don't be so quick to condemn your DBA.
How complicated is the database update? If it is a very simple update without a whole lot of data massaging taking place, then using only a Job may be appropriate. Using the principle of KISS, why involve both a DTS package and a scheduled job if you can accomplish the task by using only a Job?
On the other hand (and this is something I have not had personal experience with, so I am only speculating), I have seen that error messages from a SQL Agent Job (at least when running a DTS package) are not very helpful. In the ease of maintenance category, I would have to say DTS (at least in my experience) leave the SQL Agent Job in the dust.
And, maybe it's just that your DBA does not have experience with DTS and doesn't know its capabilities.
Is it really worth it to butt heads with your DBA? For now I would say that if you can do the update with only a SQL Agent Job, go with that. Later, if a problem arises which DTS could take care of, point this out (in a helpful, friendly way) to your DBA. Also, make a case for DTS vs. SQL Agent Job and present it to your DBA. Cooperation works a whole lot better than confrontation.
- Thread starter
- #6
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question