Job ran for -95444:-89:-43 hours ?

I have a nightly job that runs at 2.00 AM...On saturday night first it ran
for -95444:-89:-43 and again ran at 2.00 AM
I know this occured beacuse we went back one hr on saturday night at 2.00
AM...My question is why the job should run again resulting in a failed
status? SQL Server should not have run this the second time. I hope in SQL
2005 this does not happen.
Thanks,
RangaHi
This would depend on when/how the next run date is calculated. This may be
how the scheduler is designed to work. If you moved the job off the hour you
should not see this occurring.
John
"Ranga" wrote:

> I have a nightly job that runs at 2.00 AM...On saturday night first it ra
n
> for -95444:-89:-43 and again ran at 2.00 AM
> I know this occured beacuse we went back one hr on saturday night at 2.00
> AM...My question is why the job should run again resulting in a failed
> status? SQL Server should not have run this the second time. I hope in SQ
L
> 2005 this does not happen.
> Thanks,
> Ranga

Job ran for -95444:-89:-43 hours ?

I have a nightly job that runs at 2.00 AM...On saturday night first it ran
for -95444:-89:-43 and again ran at 2.00 AM
I know this occured beacuse we went back one hr on saturday night at 2.00
AM...My question is why the job should run again resulting in a failed
status? SQL Server should not have run this the second time. I hope in SQL
2005 this does not happen.
Thanks,
RangaHi
This would depend on when/how the next run date is calculated. This may be
how the scheduler is designed to work. If you moved the job off the hour you
should not see this occurring.
John
"Ranga" wrote:
> I have a nightly job that runs at 2.00 AM...On saturday night first it ran
> for -95444:-89:-43 and again ran at 2.00 AM
> I know this occured beacuse we went back one hr on saturday night at 2.00
> AM...My question is why the job should run again resulting in a failed
> status? SQL Server should not have run this the second time. I hope in SQL
> 2005 this does not happen.
> Thanks,
> Ranga

Job Failure

I have a job that runs stored procedures. I ran the stored
procedures in the correct order myself and they ran fine.
But when I try to run them in a job the job fails
immediately. I tried changing the user for the job so
that it matches the creator of the database and stored
procedures, and the job still failed. So then I wrote the
output of the job to a file, and this is the error that is
happening.
Msg 7399, Sev 16: OLE DB provider 'SQLOLEDB' reported an
error. [SQLSTATE 42000]
Msg 7312, Sev 16: [SQLSTATE 01000]
Does anyone have any ideas?
Thank you for your assistance,
AdamIs the job owner sysadmin? Are you accessing linked server?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Adam" <anonymous@.discussions.microsoft.com> wrote in message news:fed501c411be$81b90020$a6
01280a@.phx.gbl...
> I have a job that runs stored procedures. I ran the stored
> procedures in the correct order myself and they ran fine.
> But when I try to run them in a job the job fails
> immediately. I tried changing the user for the job so
> that it matches the creator of the database and stored
> procedures, and the job still failed. So then I wrote the
> output of the job to a file, and this is the error that is
> happening.
> Msg 7399, Sev 16: OLE DB provider 'SQLOLEDB' reported an
> error. [SQLSTATE 42000]
> Msg 7312, Sev 16: [SQLSTATE 01000]
> Does anyone have any ideas?
> Thank you for your assistance,
> Adam|||Yes, I am accessing several linked servers. I have tried
running the job with the owner as sysadmin and as another
user. Both fail.
>--Original Message--
>Is the job owner sysadmin? Are you accessing linked
server?
>--
>Tibor Karaszi, SQL Server MVP
>http://www.karaszi.com/sqlserver/default.asp
>
>"Adam" <anonymous@.discussions.microsoft.com> wrote in
message news:fed501c411be$81b90020$a601280a@.phx.gbl...
stored
fine.
the
is
>
>.
>|||Do you get the same error regardless of which login owns the job?
You will get problems is the job owner isn't sysadmin, as Agent then tries t
o emulate the job owner's login's
user name in the database using the SETUSER command. And after executing SET
USER, you are not allowed to do
operations at the server level. accessing linked server is a server (long) l
evel operation.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
<anonymous@.discussions.microsoft.com> wrote in message news:12d7401c411df$be50c4c0$a401280a
@.phx.gbl...
> Yes, I am accessing several linked servers. I have tried
> running the job with the owner as sysadmin and as another
> user. Both fail.
> server?
> message news:fed501c411be$81b90020$a601280a@.phx.gbl...
> stored
> fine.
> the
> is|||Yes, I have tried running the job as the database's owner
and as the 'sa' system account. Both fail, yet both are
set up to use a valid account on the linked servers. I
have this same setup on another server linked to the same
servers, and it works just fine.
>--Original Message--
>Do you get the same error regardless of which login owns
the job?
>You will get problems is the job owner isn't sysadmin, as
Agent then tries to emulate the job owner's login's
>user name in the database using the SETUSER command. And
after executing SETUSER, you are not allowed to do
>operations at the server level. accessing linked server
is a server (long) level operation.
>--
>Tibor Karaszi, SQL Server MVP
>http://www.karaszi.com/sqlserver/default.asp
>
><anonymous@.discussions.microsoft.com> wrote in message
news:12d7401c411df$be50c4c0$a401280a@.phx
.gbl...
tried
another
so
stored
wrote
that
reported an
>
>.
>|||I see... There goes my theory. I'm afraid I'm out of ideas, then. If you hav
e searched KB and are on current
service pack, and you don't get other suggestions here, I suppose its MS PSS
time.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Adam" <anonymous@.discussions.microsoft.com> wrote in message news:1339b01c411ec$094cd200$a
101280a@.phx.gbl...
> Yes, I have tried running the job as the database's owner
> and as the 'sa' system account. Both fail, yet both are
> set up to use a valid account on the linked servers. I
> have this same setup on another server linked to the same
> servers, and it works just fine.
> the job?
> Agent then tries to emulate the job owner's login's
> after executing SETUSER, you are not allowed to do
> is a server (long) level operation.
> news:12d7401c411df$be50c4c0$a401280a@.phx
.gbl...
> tried
> another
> so
> stored
> wrote
> that
> reported an

Job Execution Issue - SQL Server 2005

All,
I have a job set up to automatically execute an SSIS package. The
package itself, when ran, works fine. But when the job runs, it fails.
I looked at the sysjobhistory table in the 'msdb' database to see what
the error was. There were two entries:
1) The job failed. The Job was invoked by User DOMAIN\Administrator.
The last step to run was step 1 (Execute LBL Package).
2) Executed as user: DOMAIN\System. The package execution failed. The
step failed.
Ok, so then I went into services and changed the SQLSERVERAGENT to run
as "Administrator" instead of "System".
So, I ran the job again. Got an error. Here's what the sysjobhistory
table said this time:
1) The job failed. The Job was invoked by User DOMAIN\Administrator.
The last step to run was step 1 (Execute LBL Package).
2) Executed as user: DOMAIN\Administrator. The package execution
failed. The step failed.
WTF'!?
Thanks in advance,
JeremyProbably best asked over in the dts forum.
You need some more detail, turn on logging, but could it have something to
do with the "protection levels" of SSIS packages? Can you run it from the
command line on the same machine where it fails? Was it developed on a
different machine from where it fails? Look into how SSIS encrypts
"sensitive information" (mostly passwords), and how that has to be handled
for deployment. Also look to see who owns the job, there's something about
job owner and cmd steps, or something like that.
I've been having the same fun over the past few days. Got mine working, but
not at all certain I could enumerate all the hurdles passed.
Josh
"jrcapp@.cre8iveweb.com" wrote:
> All,
> I have a job set up to automatically execute an SSIS package. The
> package itself, when ran, works fine. But when the job runs, it fails.
> I looked at the sysjobhistory table in the 'msdb' database to see what
> the error was. There were two entries:
> 1) The job failed. The Job was invoked by User DOMAIN\Administrator.
> The last step to run was step 1 (Execute LBL Package).
> 2) Executed as user: DOMAIN\System. The package execution failed. The
> step failed.
> Ok, so then I went into services and changed the SQLSERVERAGENT to run
> as "Administrator" instead of "System".
> So, I ran the job again. Got an error. Here's what the sysjobhistory
> table said this time:
> 1) The job failed. The Job was invoked by User DOMAIN\Administrator.
> The last step to run was step 1 (Execute LBL Package).
> 2) Executed as user: DOMAIN\Administrator. The package execution
> failed. The step failed.
>
> WTF'!?
> Thanks in advance,
> Jeremy
>|||Thanks for the reply, Josh! I'll play around w/some of your
suggestions and get back to you.
Thanks,
Jeremy

Job Execution Issue - SQL Server 2005

All,
I have a job set up to automatically execute an SSIS package. The
package itself, when ran, works fine. But when the job runs, it fails.
I looked at the sysjobhistory table in the 'msdb' database to see what
the error was. There were two entries:
1) The job failed. The Job was invoked by User DOMAIN\Administrator.
The last step to run was step 1 (Execute LBL Package).
2) Executed as user: DOMAIN\System. The package execution failed. The
step failed.
Ok, so then I went into services and changed the SQLSERVERAGENT to run
as "Administrator" instead of "System".
So, I ran the job again. Got an error. Here's what the sysjobhistory
table said this time:
1) The job failed. The Job was invoked by User DOMAIN\Administrator.
The last step to run was step 1 (Execute LBL Package).
2) Executed as user: DOMAIN\Administrator. The package execution
failed. The step failed.
WTF'!?
Thanks in advance,
JeremyProbably best asked over in the dts forum.
You need some more detail, turn on logging, but could it have something to
do with the "protection levels" of SSIS packages? Can you run it from the
command line on the same machine where it fails? Was it developed on a
different machine from where it fails? Look into how SSIS encrypts
"sensitive information" (mostly passwords), and how that has to be handled
for deployment. Also look to see who owns the job, there's something about
job owner and cmd steps, or something like that.
I've been having the same fun over the past few days. Got mine working, but
not at all certain I could enumerate all the hurdles passed.
Josh
"jrcapp@.cre8iveweb.com" wrote:

> All,
> I have a job set up to automatically execute an SSIS package. The
> package itself, when ran, works fine. But when the job runs, it fails.
> I looked at the sysjobhistory table in the 'msdb' database to see what
> the error was. There were two entries:
> 1) The job failed. The Job was invoked by User DOMAIN\Administrator.
> The last step to run was step 1 (Execute LBL Package).
> 2) Executed as user: DOMAIN\System. The package execution failed. The
> step failed.
> Ok, so then I went into services and changed the SQLSERVERAGENT to run
> as "Administrator" instead of "System".
> So, I ran the job again. Got an error. Here's what the sysjobhistory
> table said this time:
> 1) The job failed. The Job was invoked by User DOMAIN\Administrator.
> The last step to run was step 1 (Execute LBL Package).
> 2) Executed as user: DOMAIN\Administrator. The package execution
> failed. The step failed.
>
> WTF'!?
> Thanks in advance,
> Jeremy
>|||Thanks for the reply, Josh! I'll play around w/some of your
suggestions and get back to you.
Thanks,
Jeremy

Job Execution Issue - SQL Server 2005

All,
I have a job set up to automatically execute an SSIS package. The
package itself, when ran, works fine. But when the job runs, it fails.
I looked at the sysjobhistory table in the 'msdb' database to see what
the error was. There were two entries:
1) The job failed. The Job was invoked by User DOMAIN\Administrator.
The last step to run was step 1 (Execute LBL Package).
2) Executed as user: DOMAIN\System. The package execution failed. The
step failed.
Ok, so then I went into services and changed the SQLSERVERAGENT to run
as "Administrator" instead of "System".
So, I ran the job again. Got an error. Here's what the sysjobhistory
table said this time:
1) The job failed. The Job was invoked by User DOMAIN\Administrator.
The last step to run was step 1 (Execute LBL Package).
2) Executed as user: DOMAIN\Administrator. The package execution
failed. The step failed.
WTF?!?
Thanks in advance,
Jeremy
Probably best asked over in the dts forum.
You need some more detail, turn on logging, but could it have something to
do with the "protection levels" of SSIS packages? Can you run it from the
command line on the same machine where it fails? Was it developed on a
different machine from where it fails? Look into how SSIS encrypts
"sensitive information" (mostly passwords), and how that has to be handled
for deployment. Also look to see who owns the job, there's something about
job owner and cmd steps, or something like that.
I've been having the same fun over the past few days. Got mine working, but
not at all certain I could enumerate all the hurdles passed.
Josh
"jrcapp@.cre8iveweb.com" wrote:

> All,
> I have a job set up to automatically execute an SSIS package. The
> package itself, when ran, works fine. But when the job runs, it fails.
> I looked at the sysjobhistory table in the 'msdb' database to see what
> the error was. There were two entries:
> 1) The job failed. The Job was invoked by User DOMAIN\Administrator.
> The last step to run was step 1 (Execute LBL Package).
> 2) Executed as user: DOMAIN\System. The package execution failed. The
> step failed.
> Ok, so then I went into services and changed the SQLSERVERAGENT to run
> as "Administrator" instead of "System".
> So, I ran the job again. Got an error. Here's what the sysjobhistory
> table said this time:
> 1) The job failed. The Job was invoked by User DOMAIN\Administrator.
> The last step to run was step 1 (Execute LBL Package).
> 2) Executed as user: DOMAIN\Administrator. The package execution
> failed. The step failed.
>
> WTF?!?
> Thanks in advance,
> Jeremy
>
|||Thanks for the reply, Josh! I'll play around w/some of your
suggestions and get back to you.
Thanks,
Jeremy