May 7, 2009 at 7:50 am
I was thinking that SQL Agent was all we needed to create scheduled jobs that could script a daily export to file. My app vendor is pushing for SSIS but whoever did the 05 install generated a ton of error logs and walked away (could be this very guy that did that). I'd rather not add more problems, given how long it took me to get Agent to even run. And then I had to move on.
This is an important app for us, and I do not have need for dts services otherwise.
I guess I'm concerned about adding further instability and the risk seems to outweigh what I'm not seeing as a reward!
May 7, 2009 at 7:55 am
SSIS is just a very useful tool to create packages that are very efficient if you develop them right. SQL Agent is an agent that helps to run scheduled tasks including SSIS packages, scripts, etc. It is not one or another – it is one plus another. You can’t substitute one by another. Without started SQL Agent you can’t run any scheduled job.
Alex Prusakov
May 7, 2009 at 9:27 am
Right, Agent is always must-have or I cannot automate backups and maintenance.
I just want to avoid adding SSIS because I don't need it and believe that automating an export does not require it.
May 7, 2009 at 10:11 am
Would you like to use command line or GUI? I prefer GUI however I know how to use command line. SSIS is very good tool. Why would not you use it if you already have it in place? I am old and lazy, thus I would use SSIS every time I can… You see my point?
Alex Prusakov
May 7, 2009 at 11:06 am
It isn't in place, see, and whoever put SQL 2005 on screwed things up pretty royally, rending Agent itself corrupt. it took a good long time to get that fixed. I am resistant to adding another component into an already unstable environment given the volume of errors on the original 2000>2005 upgrade that this guy walked away from, leaving me holding the bag.
This is an important production app serving our customers. If I don't need to add it, I don't want to. Risk aversion.
It's a commercial app, I won't be producing any dts packages from it. The current export is a short-term need, becoming obsolete in October.
Why not just schedule a little job in Agent and be done with it?
May 7, 2009 at 11:40 am
Wow, you didn’t say anything about messed up installation and other stuff. Your assumption “Do not add anything to production that is not absolutely necessary” is correct. Thus you should be the king. You should be making a call. However, this is third party application. That means that whatever this third party decides – you have to follow: for example, Microsoft deleted Notification service. Can you do anything about it? So, present you case to the boss: I am sure we do not need anything, I can do it through Agent, SSIS is messed up and there is a risk to have problems. And let your boss decide which way to go. Unless you can take the heat 🙂
Alex Prusakov
May 7, 2009 at 11:55 am
I did mention the original upgrade was whacked in my first post. That was done while I was out of country, with no advance notice or discussion, and no one told me when I returned. I found it when there were no backups and went to investigate why.
I don't really have a boss to worry about, spend most of my time in the frying pan or fire, s'ok, that's how it is. But I really need to shut this vendor down. The app does NOT require it, just wanted to make sure that scheduled jobs could still dump data and that SSIS didn't "take over" that functionality (plenty of time spent in SQL 2000 and prior, near zil in 2005).
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply