Monday, March 19, 2012

Job failure > could this be corruption

There's this job that has been around for over 3 years it runs a DTS
package, and at the beginning of each year the DTS package it modified to
change a table name to the previous year. This year the most peculiar thing
is happening. The DTS package has been changed so that the new table name
is dbo.[Sales_2006], and when run from LOCAL PACKAGES, it runs fine. Bu
t
when the scheduled JOB runs at 5 or 6 am (I've tried many things) it fails.
HERE IS PART OF THE message pulled from HISTORY >>> Executed as user:
SQLSA. ...OnStart: Drop table [dbo].[Sales_2003] Step DTSRun OnFi
nish:
Drop table [dbo].[Sales_2003]
There is more But you get the point, The Job will not accept the new
changes, and continues to refer to the new table as sales_2003. I have;
deleted the job, saved the DTS package to a new name and scheduled that, RUN
DBCC CHECKTABLE (sysdtspackages), deleted many old versions of the DTS
package. I am a bit concerned that there may be a BIG problem, but at this
point I am not sure what to do next. I need to know what someone else
thinks this could be, what should be done to pin-point and resolve this.
Thanks!!My first guess would be the package versions...I would try
to open the package, make the changes, and then do a save as
for the package. Then schedule the job to run the new
package. Are you referencing package version in your DTS run
command? My other guess is that you are using the Schedule
Package option from the package to create the job and dtsrun
command. Schedule it yourself, write your own dtsrun command
and reference the package name.
-Sue
On Mon, 12 Feb 2007 13:29:18 -0600, "WANNABE" <breichenbach
AT istate DOT com> wrote:

>There's this job that has been around for over 3 years it runs a DTS
>package, and at the beginning of each year the DTS package it modified to
>change a table name to the previous year. This year the most peculiar thin
g
>is happening. The DTS package has been changed so that the new table name
>is dbo.[Sales_2006], and when run from LOCAL PACKAGES, it runs fine. B
ut
>when the scheduled JOB runs at 5 or 6 am (I've tried many things) it fails.
>HERE IS PART OF THE message pulled from HISTORY >>> Executed as user:
>SQLSA. ...OnStart: Drop table [dbo].[Sales_2003] Step DTSRun OnF
inish:
>Drop table [dbo].[Sales_2003]
>There is more But you get the point, The Job will not accept the new
>changes, and continues to refer to the new table as sales_2003. I have;
>deleted the job, saved the DTS package to a new name and scheduled that, RU
N
>DBCC CHECKTABLE (sysdtspackages), deleted many old versions of the DTS
>package. I am a bit concerned that there may be a BIG problem, but at this
>point I am not sure what to do next. I need to know what someone else
>thinks this could be, what should be done to pin-point and resolve this.
>Thanks!!
>

No comments:

Post a Comment