April 25, 2008 at 6:56 am
I've been having a weird problem as of late. I have a DTS Package (also tried converting it to SSIS and still the same problem). It exports data from SQL to Microsoft Access. I have it scheduled as a job that runs every morning. Over the last 2 weeks or so, I've found that it's taking longer and longer anywhere from 45 minutes to 1 1/2 hours. The weird thing is, if I run the package manually, it runs fine, and takes only a few minutes. But, when run as a job, for some reason it takes 1+ hours. Has anyone else had a problem like this? Thanks in advance.
April 28, 2008 at 8:18 am
I have a similar situation. An SSIS package that, when run in the dev studio, runs just fine and takes a couple of minutes, but when run as a scheduled job, often takes so long that it times out and fails.
Haven't been able to fix it yet, but I'll let you know when I do.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
April 28, 2008 at 8:28 am
Where is the source, destination, and VS development machine on the network?
Remember, when you run a package from the SQL Agent, it runs locally on that SQL server (which may not be the server the package is stored on). If when you are running the package locally, the Access database is local and when you run it on the server, the Access database is on a UNC path, the Jet driver can get pretty inefficient. You also want to watch out for subnet configurations that may make traffic go across unnecessary routers.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply