JOB STEPS OUT OF ORDER

Hi People, I'm facing a very strange situation !
I recently imported some jobs using a script and I
realized that all the steps are out of order when I click
on start job, for example I HAVE 4 steps and it shows like
this 4 - 2 - 3 - 1 ! WHAT IS THAT '
I also notice that when I create new JOBS all order for
the steps are wrong ! WHATA IS THAT JESUS !
Please HELP ME ! THANK'S !
.I bet you installed the MS03_031 SQL Server Patch. After
I installed this patch I had the same problem. You / we
will need to wait till the next patch. :(
-Stephen
>--Original Message--
>I know this isn't what you looking for but can you
reorder them? have you
>change your sort order in sql?
>
>Yovan Fernandez
>"Roberto Carrasco" <Roberto_carrasco@.msn.com> wrote in
message
>news:058601c377d8$151d5130$a101280a@.phx.gbl...
>> Hi People, I'm facing a very strange situation !
>> I recently imported some jobs using a script and I
>> realized that all the steps are out of order when I
click
>> on start job, for example I HAVE 4 steps and it shows
like
>> this 4 - 2 - 3 - 1 ! WHAT IS THAT '
>> I also notice that when I create new JOBS all order for
>> the steps are wrong ! WHATA IS THAT JESUS !
>> Please HELP ME ! THANK'S !
>> .
>>
>
>.
>|||Hi,
I Installed ! Jesus ! This is terrible ! This kind of
thing that happen, very sad.
We wait !
Thank's !
>--Original Message--
>I bet you installed the MS03_031 SQL Server Patch. After
>I installed this patch I had the same problem. You / we
>will need to wait till the next patch. :(
>-Stephen
>>--Original Message--
>>I know this isn't what you looking for but can you
>reorder them? have you
>>change your sort order in sql?
>>
>>Yovan Fernandez
>>"Roberto Carrasco" <Roberto_carrasco@.msn.com> wrote in
>message
>>news:058601c377d8$151d5130$a101280a@.phx.gbl...
>> Hi People, I'm facing a very strange situation !
>> I recently imported some jobs using a script and I
>> realized that all the steps are out of order when I
>click
>> on start job, for example I HAVE 4 steps and it shows
>like
>> this 4 - 2 - 3 - 1 ! WHAT IS THAT '
>> I also notice that when I create new JOBS all order for
>> the steps are wrong ! WHATA IS THAT JESUS !
>> Please HELP ME ! THANK'S !
>> .
>>
>>
>>.
>.
>|||I am having the same problem. Were you able to fins a solution?
Ashwin Mahaja
--
amahaja
----
amahajan's Profile: http://www.msusenet.com/member.php?userid=39
View this thread: http://www.msusenet.com/t-322648

Job Steps Displayed Out of Order

When selecting to start a job manually, the job steps
appear out of order (step 3 is above steps 1 and 2 and
the like).
Any ideas what is causing this, and how to correct it?And, as I said, I don't see this and can't reproduce it. So something must
be different about *your* job, which is why I asked to see the SQL script.
We're not going to be able to guess at what's wrong unless we actually have
a script that we can use to reproduce your scenario!
"Arbiter Becker" <absql@.hotmail.com> wrote in message
news:0b7e01c356a5$12262c30$a601280a@.phx.gbl...
> Note;
> The job runs fine, if running off a schedule, and is
> displayed correctly if looking at the individual job
> steps. It is only when doing the manual start option for
> the job does it display incorrectly.
>
> >--Original Message--
> >When selecting to start a job manually, the job steps
> >appear out of order (step 3 is above steps 1 and 2 and
> >the like).
> >
> >Any ideas what is causing this, and how to correct it?
> >.
> >|||Hi Arbiter,
When you say step 3, 2, 1..., do you refer to the ID shown on Steps tab, or
the number prefix you may have added in the name of each job step?
If you click on "Move step" (up and down arrows), the ID always stays in
ascending order but the actual job steps move.
Richard
"Arbiter Becker" <absql@.hotmail.com> wrote in message
news:0da801c3569f$f4d71130$a101280a@.phx.gbl...
> When selecting to start a job manually, the job steps
> appear out of order (step 3 is above steps 1 and 2 and
> the like).
> Any ideas what is causing this, and how to correct it?

Job scheduling for Packages in SQL Server 2005

-
MS Win XP Pro 2002 SP2
MS SQL Server 2005
MS Visual Studio 2005
-

Can anyone help me (even by pointing me to a documentation) in order to schedule Packages (from file system source) in SQL Server 2005.

I've configured providers logging, but still the error file doesn't give me any explanation why the error happens:
"#Fields: event,computer,operator,source,sourceid,executionid,starttime,endtime,datacode,databytes,message
OnPreValidate,PC1234,NT AUTHORITY\SYSTEM,D_AGR,{8A4FA774-F5F0-40DE-AB16-A93F27950E09},{8A918844-8E43-403D-A606-C8CB4B7D8238},31/08/2006 16:42:55,31/08/2006 16:42:55,0,0x,(null)"


I've also done the same on the Step properties under 'Logging'


In Management Studio I've added my login name and I'm the only user using the machine and I manage both Visual Studio and Management Studio


The error coming up on the job history is as follow: "Executed as user: PC1234\SYSTEM. The package execution failed. The step failed." "The job failed. The Job was invoked by User UK1\USER123. The last step to run was step 1 (step1)."


By the way the package (.dtsx) runs fine in BI Visual Studio)

Thank you very much.

I ran into the same problem this morning. The default when scheduling a package as a job is to run under the SQL Service Agent, in Visual Studio and executing the package from Sql Server Management Studio you are executing the package under your user account UK1\User123.

This causes problems for connections using Windows Authentication. Your fix might be unique as there is a couple ways to deal with this behavior.

Check out this MS article...

http://support.microsoft.com/?kbid=918760

|||

Thank you.
I went trough the steps, but didn't really get far.

I'm the only user on this pc, thus Server Name, Creator, Author etc. always refer to the same parameters. I ticked for my login all permissions available, but still...
The job that I'm trying to schedule with the SQL Server Agent is still failing. It runs fine in BI Visual Studio and also runs ok if executed from Management Studio connected to Integration Services (Stored Packages\MSDB\Maintenace Plans\Package1)

Another issue is the log file which doesn't explain much:
I've tried to set up a log file (provider for text files with all events ticked) but this is all i get:
"OnPreValidate,UKSERV01,NT AUTHORITY\SYSTEM,PACKAGE1,{A9D28A92-C509-4F1D-9630-0848B0036929},{FF9D650E-62D3-44F1-9D76-B34467E8DADC},01/09/2006 16:46:09,01/09/2006 16:46:09,0,0x,(null)"

Thanks for the link anyway

|||What is the value of the SSIS package ProtectionLevel property? We're using configuration files to save all of our secure settings and have set the value of the property to DontSaveSensitive. Using an Indirect XML Configuration to point to the configuration file containing the connection strings and using different configuration files for Production, Staging, and development. Aren't experiencing any issues with SQL Agent using this approach.|||

Hi Martin,

I've tried to use ProtectionLevel property DontSaveSensitive, EncryptSensitiveWithUserKey and ServerStorage. With each attempt I saved a copy of the package as: location=SQL Server, Windows Authentication, path= SSIS Packages\Maintenance Plans

I can see the package in Management Studio under Stored Packages\MSDB\Maintenance Plans.

I've scheduled jobs in each attempt, step type= SSIS Package, Run as= SQL Agent Service Account, Source=as above, on Data Sources I've ticked all Connection Manager, and I've set up the same Logging Provider as set up initially on the package in BI Visual Studio.

If I run the job I get the following error on the log file (this last one with ServerStorage property):
OnPreValidate,UKSERV01,NT AUTHORITY\SYSTEM,PACKAGE1,{A9D28A92-C509-4F1D-9630-0848B0036929},{73A25B5B-4CE5-45B2-A1A0-948F0B8AB9A9},06/09/2006 11:20:08,06/09/2006 11:20:08,0,0x,(null)

Any other idea on the issue? And also why isn't the log file more detailed on the actual error?

Thank you

|||

I forgot to mention that (in each attempt), if I right click the package from Management Studio and Run it, the pachage runs successefully.

|||

An error in the OnPreValidate event almost always indicates that a database connection or connection to a network file share could not be established. From the error message you're receiving, it looks as if your SQL Server Agent service is running under a local system account, NT AUTHORITY\SYSTEM. With the service running under this account assuming your database connections are using Windows Authentication, you won't be able to access any resources beyond that machine boundary when scheduling execution of your package. Have you checked to see if SQL Server Agent, and SQL Integration Services (other?) services are running on a network account that has access to all resources referenced by your package?

|||

Sorry it took be a couple days to come across this again.

You said you didn't get very far with the link and that you are the only user. Only the SQL Service Agent doesn't run under your user account. It will run under the setting you selected when installing SQL Server (Local System, Local Service, or Network Service).

Here is what I did, create a new Credential using SQL Server Management Studio (under the Security section). Give the Credential the indentity of your user account on the computer. Then under SQL Server Agent\Proxies\SSIS Package Execution create a new Proxy, assigning it the credential you created in the previous step. I checked SQL Server Integration Sercies Package subsystem.

Finally go back to your scheduled job and edit the Step that runs the SSIS Package. Under the Run As drop down you should now see your new proxy. Select it and try and run the job. I also made sure that the owner of the job was the same user as the proxy, I forget if that was nessisary or not.

Hope that helps.

|||I had the same error with a totally different solution and this may not be your issue, but I had to check the boxes under the data sources tab in my job step and it seemed to fix it.|||

Hi all.

Martin,
I confirm the Agent service property is set to 'Local system account'.
I thought this wouldn't be an issue given that I have everything on one pc where I am the only user.
ie:(local) and UKSERV01 would be the same thing, and I use my domain\account to log on the server/pc,
and use Windows Authentication, thus anything I create in BI Visual Studio and in Management Studio
should use the same account...i believe.

BSHOE,
I have already selected the data source connections. Thanks

infrandom,
as above, yes the Agent service runs as 'Local system account'.
I'm goinng to try create the Proxy and will post back the outcome.

Thanks so far guys, we'll get there eventually!

|||

an update...

i've tried the proxy solution which worked fine, but not for all packages.

I'm currently using a new server account that I use also to run the sql agent service.

Thanks all

|||

Hey, Luz.

I was dealing with the same kind of thing. Some jobs were working just fine, while others were not. The thing I noticed was that packages that dealt with flat files (thereby requiring file system access outside of the database) were the ones dying. I changed the account under which the SQL server agent ran to my domain login account and it all ran fine after that! Just thought I would share.

|||

Hi Drew

that is exactly my current setup.

Thanks for your feedback.

|||

Hi

I am having same problem too. I have package that is simple export database from one database to other and saved as SSIS package on SQL Server. but if i run that package with job along with proxy account it fails and gives me error.

and that same package i fun on my computer and if i run that by itself by right clicking on package in integration service, and then run package it runs fine!!

Why and what will be the problem?

thanks

Pat

|||

Patdev wrote:

Hi

I am having same problem too. I have package that is simple export database from one database to other and saved as SSIS package on SQL Server. but if i run that package with job along with proxy account it fails and gives me error.

and that same package i fun on my computer and if i run that by itself by right clicking on package in integration service, and then run package it runs fine!!

Why and what will be the problem?

thanks

Pat

It could be the package security's ProtectionLevel property in your case. When you save the package to the server, all password information is stripped.

There are plenty of posts on the ProtectionLevel property in this forum should you decide to research that parameter.

Job scheduling for Packages in SQL Server 2005

-
MS Win XP Pro 2002 SP2
MS SQL Server 2005
MS Visual Studio 2005
-

Can anyone help me (even by pointing me to a documentation) in order to schedule Packages (from file system source) in SQL Server 2005.

I've configured providers logging, but still the error file doesn't give me any explanation why the error happens:
"#Fields: event,computer,operator,source,sourceid,executionid,starttime,endtime,datacode,databytes,message
OnPreValidate,PC1234,NT AUTHORITY\SYSTEM,D_AGR,{8A4FA774-F5F0-40DE-AB16-A93F27950E09},{8A918844-8E43-403D-A606-C8CB4B7D8238},31/08/2006 16:42:55,31/08/2006 16:42:55,0,0x,(null)"
I've also done the same on the Step properties under 'Logging'
In Management Studio I've added my login name and I'm the only user using the machine and I manage both Visual Studio and Management Studio
The error coming up on the job history is as follow: "Executed as user: PC1234\SYSTEM. The package execution failed. The step failed." "The job failed. The Job was invoked by User UK1\USER123. The last step to run was step 1 (step1)."
By the way the package (.dtsx) runs fine in BI Visual Studio)

Thank you very much.

I ran into the same problem this morning. The default when scheduling a package as a job is to run under the SQL Service Agent, in Visual Studio and executing the package from Sql Server Management Studio you are executing the package under your user account UK1\User123.

This causes problems for connections using Windows Authentication. Your fix might be unique as there is a couple ways to deal with this behavior.

Check out this MS article...

http://support.microsoft.com/?kbid=918760

|||

Thank you.
I went trough the steps, but didn't really get far.

I'm the only user on this pc, thus Server Name, Creator, Author etc. always refer to the same parameters. I ticked for my login all permissions available, but still...
The job that I'm trying to schedule with the SQL Server Agent is still failing. It runs fine in BI Visual Studio and also runs ok if executed from Management Studio connected to Integration Services (Stored Packages\MSDB\Maintenace Plans\Package1)

Another issue is the log file which doesn't explain much:
I've tried to set up a log file (provider for text files with all events ticked) but this is all i get:
"OnPreValidate,UKSERV01,NT AUTHORITY\SYSTEM,PACKAGE1,{A9D28A92-C509-4F1D-9630-0848B0036929},{FF9D650E-62D3-44F1-9D76-B34467E8DADC},01/09/2006 16:46:09,01/09/2006 16:46:09,0,0x,(null)"

Thanks for the link anyway

|||What is the value of the SSIS package ProtectionLevel property? We're using configuration files to save all of our secure settings and have set the value of the property to DontSaveSensitive. Using an Indirect XML Configuration to point to the configuration file containing the connection strings and using different configuration files for Production, Staging, and development. Aren't experiencing any issues with SQL Agent using this approach.|||

Hi Martin,

I've tried to use ProtectionLevel property DontSaveSensitive, EncryptSensitiveWithUserKey and ServerStorage. With each attempt I saved a copy of the package as: location=SQL Server, Windows Authentication, path= SSIS Packages\Maintenance Plans

I can see the package in Management Studio under Stored Packages\MSDB\Maintenance Plans.

I've scheduled jobs in each attempt, step type= SSIS Package, Run as= SQL Agent Service Account, Source=as above, on Data Sources I've ticked all Connection Manager, and I've set up the same Logging Provider as set up initially on the package in BI Visual Studio.

If I run the job I get the following error on the log file (this last one with ServerStorage property):
OnPreValidate,UKSERV01,NT AUTHORITY\SYSTEM,PACKAGE1,{A9D28A92-C509-4F1D-9630-0848B0036929},{73A25B5B-4CE5-45B2-A1A0-948F0B8AB9A9},06/09/2006 11:20:08,06/09/2006 11:20:08,0,0x,(null)

Any other idea on the issue? And also why isn't the log file more detailed on the actual error?

Thank you

|||

I forgot to mention that (in each attempt), if I right click the package from Management Studio and Run it, the pachage runs successefully.

|||

An error in the OnPreValidate event almost always indicates that a database connection or connection to a network file share could not be established. From the error message you're receiving, it looks as if your SQL Server Agent service is running under a local system account, NT AUTHORITY\SYSTEM. With the service running under this account assuming your database connections are using Windows Authentication, you won't be able to access any resources beyond that machine boundary when scheduling execution of your package. Have you checked to see if SQL Server Agent, and SQL Integration Services (other?) services are running on a network account that has access to all resources referenced by your package?

|||

Sorry it took be a couple days to come across this again.

You said you didn't get very far with the link and that you are the only user. Only the SQL Service Agent doesn't run under your user account. It will run under the setting you selected when installing SQL Server (Local System, Local Service, or Network Service).

Here is what I did, create a new Credential using SQL Server Management Studio (under the Security section). Give the Credential the indentity of your user account on the computer. Then under SQL Server Agent\Proxies\SSIS Package Execution create a new Proxy, assigning it the credential you created in the previous step. I checked SQL Server Integration Sercies Package subsystem.

Finally go back to your scheduled job and edit the Step that runs the SSIS Package. Under the Run As drop down you should now see your new proxy. Select it and try and run the job. I also made sure that the owner of the job was the same user as the proxy, I forget if that was nessisary or not.

Hope that helps.

|||I had the same error with a totally different solution and this may not be your issue, but I had to check the boxes under the data sources tab in my job step and it seemed to fix it.|||

Hi all.

Martin,
I confirm the Agent service property is set to 'Local system account'.
I thought this wouldn't be an issue given that I have everything on one pc where I am the only user.
ie:(local) and UKSERV01 would be the same thing, and I use my domain\account to log on the server/pc,
and use Windows Authentication, thus anything I create in BI Visual Studio and in Management Studio
should use the same account...i believe.

BSHOE,
I have already selected the data source connections. Thanks

infrandom,
as above, yes the Agent service runs as 'Local system account'.
I'm goinng to try create the Proxy and will post back the outcome.

Thanks so far guys, we'll get there eventually!

|||

an update...

i've tried the proxy solution which worked fine, but not for all packages.

I'm currently using a new server account that I use also to run the sql agent service.

Thanks all

|||

Hey, Luz.

I was dealing with the same kind of thing. Some jobs were working just fine, while others were not. The thing I noticed was that packages that dealt with flat files (thereby requiring file system access outside of the database) were the ones dying. I changed the account under which the SQL server agent ran to my domain login account and it all ran fine after that! Just thought I would share.

|||

Hi Drew

that is exactly my current setup.

Thanks for your feedback.

|||

Hi

I am having same problem too. I have package that is simple export database from one database to other and saved as SSIS package on SQL Server. but if i run that package with job along with proxy account it fails and gives me error.

and that same package i fun on my computer and if i run that by itself by right clicking on package in integration service, and then run package it runs fine!!

Why and what will be the problem?

thanks

Pat

|||

Patdev wrote:

Hi

I am having same problem too. I have package that is simple export database from one database to other and saved as SSIS package on SQL Server. but if i run that package with job along with proxy account it fails and gives me error.

and that same package i fun on my computer and if i run that by itself by right clicking on package in integration service, and then run package it runs fine!!

Why and what will be the problem?

thanks

Pat

It could be the package security's ProtectionLevel property in your case. When you save the package to the server, all password information is stripped.

There are plenty of posts on the ProtectionLevel property in this forum should you decide to research that parameter.sql

Job scheduling for Packages in SQL Server 2005

-
MS Win XP Pro 2002 SP2
MS SQL Server 2005
MS Visual Studio 2005
-

Can anyone help me (even by pointing me to a documentation) in order to schedule Packages (from file system source) in SQL Server 2005.

I've configured providers logging, but still the error file doesn't give me any explanation why the error happens:
"#Fields: event,computer,operator,source,sourceid,executionid,starttime,endtime,datacode,databytes,message
OnPreValidate,PC1234,NT AUTHORITY\SYSTEM,D_AGR,{8A4FA774-F5F0-40DE-AB16-A93F27950E09},{8A918844-8E43-403D-A606-C8CB4B7D8238},31/08/2006 16:42:55,31/08/2006 16:42:55,0,0x,(null)"


I've also done the same on the Step properties under 'Logging'


In Management Studio I've added my login name and I'm the only user using the machine and I manage both Visual Studio and Management Studio


The error coming up on the job history is as follow: "Executed as user: PC1234\SYSTEM. The package execution failed. The step failed." "The job failed. The Job was invoked by User UK1\USER123. The last step to run was step 1 (step1)."


By the way the package (.dtsx) runs fine in BI Visual Studio)

Thank you very much.

I ran into the same problem this morning. The default when scheduling a package as a job is to run under the SQL Service Agent, in Visual Studio and executing the package from Sql Server Management Studio you are executing the package under your user account UK1\User123.

This causes problems for connections using Windows Authentication. Your fix might be unique as there is a couple ways to deal with this behavior.

Check out this MS article...

http://support.microsoft.com/?kbid=918760

|||

Thank you.
I went trough the steps, but didn't really get far.

I'm the only user on this pc, thus Server Name, Creator, Author etc. always refer to the same parameters. I ticked for my login all permissions available, but still...
The job that I'm trying to schedule with the SQL Server Agent is still failing. It runs fine in BI Visual Studio and also runs ok if executed from Management Studio connected to Integration Services (Stored Packages\MSDB\Maintenace Plans\Package1)

Another issue is the log file which doesn't explain much:
I've tried to set up a log file (provider for text files with all events ticked) but this is all i get:
"OnPreValidate,UKSERV01,NT AUTHORITY\SYSTEM,PACKAGE1,{A9D28A92-C509-4F1D-9630-0848B0036929},{FF9D650E-62D3-44F1-9D76-B34467E8DADC},01/09/2006 16:46:09,01/09/2006 16:46:09,0,0x,(null)"

Thanks for the link anyway

|||What is the value of the SSIS package ProtectionLevel property? We're using configuration files to save all of our secure settings and have set the value of the property to DontSaveSensitive. Using an Indirect XML Configuration to point to the configuration file containing the connection strings and using different configuration files for Production, Staging, and development. Aren't experiencing any issues with SQL Agent using this approach.|||

Hi Martin,

I've tried to use ProtectionLevel property DontSaveSensitive, EncryptSensitiveWithUserKey and ServerStorage. With each attempt I saved a copy of the package as: location=SQL Server, Windows Authentication, path= SSIS Packages\Maintenance Plans

I can see the package in Management Studio under Stored Packages\MSDB\Maintenance Plans.

I've scheduled jobs in each attempt, step type= SSIS Package, Run as= SQL Agent Service Account, Source=as above, on Data Sources I've ticked all Connection Manager, and I've set up the same Logging Provider as set up initially on the package in BI Visual Studio.

If I run the job I get the following error on the log file (this last one with ServerStorage property):
OnPreValidate,UKSERV01,NT AUTHORITY\SYSTEM,PACKAGE1,{A9D28A92-C509-4F1D-9630-0848B0036929},{73A25B5B-4CE5-45B2-A1A0-948F0B8AB9A9},06/09/2006 11:20:08,06/09/2006 11:20:08,0,0x,(null)

Any other idea on the issue? And also why isn't the log file more detailed on the actual error?

Thank you

|||

I forgot to mention that (in each attempt), if I right click the package from Management Studio and Run it, the pachage runs successefully.

|||

An error in the OnPreValidate event almost always indicates that a database connection or connection to a network file share could not be established. From the error message you're receiving, it looks as if your SQL Server Agent service is running under a local system account, NT AUTHORITY\SYSTEM. With the service running under this account assuming your database connections are using Windows Authentication, you won't be able to access any resources beyond that machine boundary when scheduling execution of your package. Have you checked to see if SQL Server Agent, and SQL Integration Services (other?) services are running on a network account that has access to all resources referenced by your package?

|||

Sorry it took be a couple days to come across this again.

You said you didn't get very far with the link and that you are the only user. Only the SQL Service Agent doesn't run under your user account. It will run under the setting you selected when installing SQL Server (Local System, Local Service, or Network Service).

Here is what I did, create a new Credential using SQL Server Management Studio (under the Security section). Give the Credential the indentity of your user account on the computer. Then under SQL Server Agent\Proxies\SSIS Package Execution create a new Proxy, assigning it the credential you created in the previous step. I checked SQL Server Integration Sercies Package subsystem.

Finally go back to your scheduled job and edit the Step that runs the SSIS Package. Under the Run As drop down you should now see your new proxy. Select it and try and run the job. I also made sure that the owner of the job was the same user as the proxy, I forget if that was nessisary or not.

Hope that helps.

|||I had the same error with a totally different solution and this may not be your issue, but I had to check the boxes under the data sources tab in my job step and it seemed to fix it.|||

Hi all.

Martin,
I confirm the Agent service property is set to 'Local system account'.
I thought this wouldn't be an issue given that I have everything on one pc where I am the only user.
ie:(local) and UKSERV01 would be the same thing, and I use my domain\account to log on the server/pc,
and use Windows Authentication, thus anything I create in BI Visual Studio and in Management Studio
should use the same account...i believe.

BSHOE,
I have already selected the data source connections. Thanks

infrandom,
as above, yes the Agent service runs as 'Local system account'.
I'm goinng to try create the Proxy and will post back the outcome.

Thanks so far guys, we'll get there eventually!

|||

an update...

i've tried the proxy solution which worked fine, but not for all packages.

I'm currently using a new server account that I use also to run the sql agent service.

Thanks all

|||

Hey, Luz.

I was dealing with the same kind of thing. Some jobs were working just fine, while others were not. The thing I noticed was that packages that dealt with flat files (thereby requiring file system access outside of the database) were the ones dying. I changed the account under which the SQL server agent ran to my domain login account and it all ran fine after that! Just thought I would share.

|||

Hi Drew

that is exactly my current setup.

Thanks for your feedback.

|||

Hi

I am having same problem too. I have package that is simple export database from one database to other and saved as SSIS package on SQL Server. but if i run that package with job along with proxy account it fails and gives me error.

and that same package i fun on my computer and if i run that by itself by right clicking on package in integration service, and then run package it runs fine!!

Why and what will be the problem?

thanks

Pat

|||

Patdev wrote:

Hi

I am having same problem too. I have package that is simple export database from one database to other and saved as SSIS package on SQL Server. but if i run that package with job along with proxy account it fails and gives me error.

and that same package i fun on my computer and if i run that by itself by right clicking on package in integration service, and then run package it runs fine!!

Why and what will be the problem?

thanks

Pat

It could be the package security's ProtectionLevel property in your case. When you save the package to the server, all password information is stripped.

There are plenty of posts on the ProtectionLevel property in this forum should you decide to research that parameter.

Job scheduling for Packages in SQL Server 2005

-
MS Win XP Pro 2002 SP2
MS SQL Server 2005
MS Visual Studio 2005
-

Can anyone help me (even by pointing me to a documentation) in order to schedule Packages (from file system source) in SQL Server 2005.

I've configured providers logging, but still the error file doesn't give me any explanation why the error happens:
"#Fields: event,computer,operator,source,sourceid,executionid,starttime,endtime,datacode,databytes,message
OnPreValidate,PC1234,NT AUTHORITY\SYSTEM,D_AGR,{8A4FA774-F5F0-40DE-AB16-A93F27950E09},{8A918844-8E43-403D-A606-C8CB4B7D8238},31/08/2006 16:42:55,31/08/2006 16:42:55,0,0x,(null)"


I've also done the same on the Step properties under 'Logging'


In Management Studio I've added my login name and I'm the only user using the machine and I manage both Visual Studio and Management Studio


The error coming up on the job history is as follow: "Executed as user: PC1234\SYSTEM. The package execution failed. The step failed." "The job failed. The Job was invoked by User UK1\USER123. The last step to run was step 1 (step1)."


By the way the package (.dtsx) runs fine in BI Visual Studio)

Thank you very much.

I ran into the same problem this morning. The default when scheduling a package as a job is to run under the SQL Service Agent, in Visual Studio and executing the package from Sql Server Management Studio you are executing the package under your user account UK1\User123.

This causes problems for connections using Windows Authentication. Your fix might be unique as there is a couple ways to deal with this behavior.

Check out this MS article...

http://support.microsoft.com/?kbid=918760

|||

Thank you.
I went trough the steps, but didn't really get far.

I'm the only user on this pc, thus Server Name, Creator, Author etc. always refer to the same parameters. I ticked for my login all permissions available, but still...
The job that I'm trying to schedule with the SQL Server Agent is still failing. It runs fine in BI Visual Studio and also runs ok if executed from Management Studio connected to Integration Services (Stored Packages\MSDB\Maintenace Plans\Package1)

Another issue is the log file which doesn't explain much:
I've tried to set up a log file (provider for text files with all events ticked) but this is all i get:
"OnPreValidate,UKSERV01,NT AUTHORITY\SYSTEM,PACKAGE1,{A9D28A92-C509-4F1D-9630-0848B0036929},{FF9D650E-62D3-44F1-9D76-B34467E8DADC},01/09/2006 16:46:09,01/09/2006 16:46:09,0,0x,(null)"

Thanks for the link anyway

|||What is the value of the SSIS package ProtectionLevel property? We're using configuration files to save all of our secure settings and have set the value of the property to DontSaveSensitive. Using an Indirect XML Configuration to point to the configuration file containing the connection strings and using different configuration files for Production, Staging, and development. Aren't experiencing any issues with SQL Agent using this approach.|||

Hi Martin,

I've tried to use ProtectionLevel property DontSaveSensitive, EncryptSensitiveWithUserKey and ServerStorage. With each attempt I saved a copy of the package as: location=SQL Server, Windows Authentication, path= SSIS Packages\Maintenance Plans

I can see the package in Management Studio under Stored Packages\MSDB\Maintenance Plans.

I've scheduled jobs in each attempt, step type= SSIS Package, Run as= SQL Agent Service Account, Source=as above, on Data Sources I've ticked all Connection Manager, and I've set up the same Logging Provider as set up initially on the package in BI Visual Studio.

If I run the job I get the following error on the log file (this last one with ServerStorage property):
OnPreValidate,UKSERV01,NT AUTHORITY\SYSTEM,PACKAGE1,{A9D28A92-C509-4F1D-9630-0848B0036929},{73A25B5B-4CE5-45B2-A1A0-948F0B8AB9A9},06/09/2006 11:20:08,06/09/2006 11:20:08,0,0x,(null)

Any other idea on the issue? And also why isn't the log file more detailed on the actual error?

Thank you

|||

I forgot to mention that (in each attempt), if I right click the package from Management Studio and Run it, the pachage runs successefully.

|||

An error in the OnPreValidate event almost always indicates that a database connection or connection to a network file share could not be established. From the error message you're receiving, it looks as if your SQL Server Agent service is running under a local system account, NT AUTHORITY\SYSTEM. With the service running under this account assuming your database connections are using Windows Authentication, you won't be able to access any resources beyond that machine boundary when scheduling execution of your package. Have you checked to see if SQL Server Agent, and SQL Integration Services (other?) services are running on a network account that has access to all resources referenced by your package?

|||

Sorry it took be a couple days to come across this again.

You said you didn't get very far with the link and that you are the only user. Only the SQL Service Agent doesn't run under your user account. It will run under the setting you selected when installing SQL Server (Local System, Local Service, or Network Service).

Here is what I did, create a new Credential using SQL Server Management Studio (under the Security section). Give the Credential the indentity of your user account on the computer. Then under SQL Server Agent\Proxies\SSIS Package Execution create a new Proxy, assigning it the credential you created in the previous step. I checked SQL Server Integration Sercies Package subsystem.

Finally go back to your scheduled job and edit the Step that runs the SSIS Package. Under the Run As drop down you should now see your new proxy. Select it and try and run the job. I also made sure that the owner of the job was the same user as the proxy, I forget if that was nessisary or not.

Hope that helps.

|||I had the same error with a totally different solution and this may not be your issue, but I had to check the boxes under the data sources tab in my job step and it seemed to fix it.|||

Hi all.

Martin,
I confirm the Agent service property is set to 'Local system account'.
I thought this wouldn't be an issue given that I have everything on one pc where I am the only user.
ie:(local) and UKSERV01 would be the same thing, and I use my domain\account to log on the server/pc,
and use Windows Authentication, thus anything I create in BI Visual Studio and in Management Studio
should use the same account...i believe.

BSHOE,
I have already selected the data source connections. Thanks

infrandom,
as above, yes the Agent service runs as 'Local system account'.
I'm goinng to try create the Proxy and will post back the outcome.

Thanks so far guys, we'll get there eventually!

|||

an update...

i've tried the proxy solution which worked fine, but not for all packages.

I'm currently using a new server account that I use also to run the sql agent service.

Thanks all

|||

Hey, Luz.

I was dealing with the same kind of thing. Some jobs were working just fine, while others were not. The thing I noticed was that packages that dealt with flat files (thereby requiring file system access outside of the database) were the ones dying. I changed the account under which the SQL server agent ran to my domain login account and it all ran fine after that! Just thought I would share.

|||

Hi Drew

that is exactly my current setup.

Thanks for your feedback.

|||

Hi

I am having same problem too. I have package that is simple export database from one database to other and saved as SSIS package on SQL Server. but if i run that package with job along with proxy account it fails and gives me error.

and that same package i fun on my computer and if i run that by itself by right clicking on package in integration service, and then run package it runs fine!!

Why and what will be the problem?

thanks

Pat

|||

Patdev wrote:

Hi

I am having same problem too. I have package that is simple export database from one database to other and saved as SSIS package on SQL Server. but if i run that package with job along with proxy account it fails and gives me error.

and that same package i fun on my computer and if i run that by itself by right clicking on package in integration service, and then run package it runs fine!!

Why and what will be the problem?

thanks

Pat

It could be the package security's ProtectionLevel property in your case. When you save the package to the server, all password information is stripped.

There are plenty of posts on the ProtectionLevel property in this forum should you decide to research that parameter.

Job runs succesfully, but database not updated

I have created a job to run an executable. This executable has to read an
Excelsheet in order to import the data into the database.
I got the message that the job has run succesfully, but the data is not in
the database.
My job looks like this:
c:\mydirectory\bin\excelimport.exe /Slocal) /D:DataComp 20051020
S: --> the local server
D:--> database name
Thank you for your help.
Kind regards,
LoHi
You don't say where the job expects the excel file to be! Have you looks at
SQL profiler to see what is happening when the program runs?
John
"lo" wrote:

> I have created a job to run an executable. This executable has to read an
> Excelsheet in order to import the data into the database.
> I got the message that the job has run succesfully, but the data is not in
> the database.
> My job looks like this:
> c:\mydirectory\bin\excelimport.exe /Slocal) /D:DataComp 20051020
> S: --> the local server
> D:--> database name
> --
> Thank you for your help.
> Kind regards,
> Lo|||I have run the profiler, but here as well I get no error message once or eve
r.
I have updated the string like this
c:\mydirectory\bin\excelimport.exe /Slocal) /D:[DataComp 20051020]
The path to the excel sheet is in the excelimport.exe.
Do you have any other idea'
Thank you for your help.
Kind regards,
Lo
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> You don't say where the job expects the excel file to be! Have you looks a
t
> SQL profiler to see what is happening when the program runs?
> John
> "lo" wrote:
>|||Hi
I would not expect any error messages from SQL Profile, just the information
about which database it is running against and what SQL statements are being
executed by the job. You can then confirm that it is not connecting to the
correct database or that it is not finding the file.
Do you have a dynamic properties task to change the destination database?
You may want to see http://www.sqldts.com/default.aspx?252
John
"lo" wrote:
[vbcol=seagreen]
> I have run the profiler, but here as well I get no error message once or e
ver.
> I have updated the string like this
> c:\mydirectory\bin\excelimport.exe /Slocal) /D:[DataComp 20051020]
> The path to the excel sheet is in the excelimport.exe.
> Do you have any other idea'
>
> --
> Thank you for your help.
> Kind regards,
> Lo
>
> "John Bell" wrote:
>

Job runs succesfully, but database not updated

I have created a job to run an executable. This executable has to read an
Excelsheet in order to import the data into the database.
I got the message that the job has run succesfully, but the data is not in
the database.
My job looks like this:
c:\mydirectory\bin\excelimport.exe /S:(local) /D:DataComp 20051020
S: --> the local server
D:--> database name
--
Thank you for your help.
Kind regards,
LoHi
You don't say where the job expects the excel file to be! Have you looks at
SQL profiler to see what is happening when the program runs?
John
"lo" wrote:
> I have created a job to run an executable. This executable has to read an
> Excelsheet in order to import the data into the database.
> I got the message that the job has run succesfully, but the data is not in
> the database.
> My job looks like this:
> c:\mydirectory\bin\excelimport.exe /S:(local) /D:DataComp 20051020
> S: --> the local server
> D:--> database name
> --
> Thank you for your help.
> Kind regards,
> Lo|||I have run the profiler, but here as well I get no error message once or ever.
I have updated the string like this
c:\mydirectory\bin\excelimport.exe /S:(local) /D:[DataComp 20051020]
The path to the excel sheet is in the excelimport.exe.
Do you have any other idea'
Thank you for your help.
Kind regards,
Lo
"John Bell" wrote:
> Hi
> You don't say where the job expects the excel file to be! Have you looks at
> SQL profiler to see what is happening when the program runs?
> John
> "lo" wrote:
> > I have created a job to run an executable. This executable has to read an
> > Excelsheet in order to import the data into the database.
> > I got the message that the job has run succesfully, but the data is not in
> > the database.
> > My job looks like this:
> > c:\mydirectory\bin\excelimport.exe /S:(local) /D:DataComp 20051020
> > S: --> the local server
> > D:--> database name
> >
> > --
> > Thank you for your help.
> >
> > Kind regards,
> >
> > Lo|||Hi
I would not expect any error messages from SQL Profile, just the information
about which database it is running against and what SQL statements are being
executed by the job. You can then confirm that it is not connecting to the
correct database or that it is not finding the file.
Do you have a dynamic properties task to change the destination database?
You may want to see http://www.sqldts.com/default.aspx?252
John
"lo" wrote:
> I have run the profiler, but here as well I get no error message once or ever.
> I have updated the string like this
> c:\mydirectory\bin\excelimport.exe /S:(local) /D:[DataComp 20051020]
> The path to the excel sheet is in the excelimport.exe.
> Do you have any other idea'
>
> --
> Thank you for your help.
> Kind regards,
> Lo
>
> "John Bell" wrote:
> > Hi
> >
> > You don't say where the job expects the excel file to be! Have you looks at
> > SQL profiler to see what is happening when the program runs?
> >
> > John
> >
> > "lo" wrote:
> >
> > > I have created a job to run an executable. This executable has to read an
> > > Excelsheet in order to import the data into the database.
> > > I got the message that the job has run succesfully, but the data is not in
> > > the database.
> > > My job looks like this:
> > > c:\mydirectory\bin\excelimport.exe /S:(local) /D:DataComp 20051020
> > > S: --> the local server
> > > D:--> database name
> > >
> > > --
> > > Thank you for your help.
> > >
> > > Kind regards,
> > >
> > > Lo

Job order

I have a job [job1] to start a trace and is scheduled to run every five
minutes:
Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
then...
If I have a job [job2] to stop the trace that was started in [job1] and is
scheduled to run every five minutes:
Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
I enable the jobs to run, and it appears that everything works great. Job1
executes for 5 minutes, followed by Job2 stopping the trace and doing what it
is asked to do. However, this seems to go against logic. Even though the
schedules for Job1 and Job2 are identical, it does not seem like they would
both execute exactly simultaneously, meaning that even though the schedules
are identical, it seems like either (in milliseconds) Job1 would execute
before Job2, or else Job2 would execute before Job1.
In the first case (Job1 before Job2), Job2 would stop Job1 after milliseconds
and no trace data would hardly ever be created. In the second case (Job2
before Job1), then Job1 does run for its five minutes before it is stopped
and restarted. So, in the second case, this is great. So far, that appears to
be what is happening, or at least my five minutes of trace is being collected,
repeatedly.
I am glad it is working like this, but it seems like it could just as easily
have Job1 execute before Job2 and hardly any trace data be collected. What
determines the order when schedules are identical?
Message posted via http://www.droptable.com
Hi
As this would be an internal undocumented feature of SQL Server you should
not rely on this staying the same between versions, therefore you should make
sure that your jobs will behave correctly regardless, for example specifying
the duration for the trace and then you would not need to stop it.
John
"cbrichards via droptable.com" wrote:

> I have a job [job1] to start a trace and is scheduled to run every five
> minutes:
> Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
> then...
> If I have a job [job2] to stop the trace that was started in [job1] and is
> scheduled to run every five minutes:
> Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
> I enable the jobs to run, and it appears that everything works great. Job1
> executes for 5 minutes, followed by Job2 stopping the trace and doing what it
> is asked to do. However, this seems to go against logic. Even though the
> schedules for Job1 and Job2 are identical, it does not seem like they would
> both execute exactly simultaneously, meaning that even though the schedules
> are identical, it seems like either (in milliseconds) Job1 would execute
> before Job2, or else Job2 would execute before Job1.
> In the first case (Job1 before Job2), Job2 would stop Job1 after milliseconds
> and no trace data would hardly ever be created. In the second case (Job2
> before Job1), then Job1 does run for its five minutes before it is stopped
> and restarted. So, in the second case, this is great. So far, that appears to
> be what is happening, or at least my five minutes of trace is being collected,
> repeatedly.
> I am glad it is working like this, but it seems like it could just as easily
> have Job1 execute before Job2 and hardly any trace data be collected. What
> determines the order when schedules are identical?
> --
> Message posted via http://www.droptable.com
>
|||In addition to John's comments, you could also just do this
in one job - the first job step to check if the trace is
running and stop it if it is. Then the second step is to
start the new trace.
-Sue
On Mon, 03 Apr 2006 23:31:34 GMT, "cbrichards via
droptable.com" <u3288@.uwe> wrote:

>I have a job [job1] to start a trace and is scheduled to run every five
>minutes:
>Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
>then...
>If I have a job [job2] to stop the trace that was started in [job1] and is
>scheduled to run every five minutes:
>Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
>I enable the jobs to run, and it appears that everything works great. Job1
>executes for 5 minutes, followed by Job2 stopping the trace and doing what it
>is asked to do. However, this seems to go against logic. Even though the
>schedules for Job1 and Job2 are identical, it does not seem like they would
>both execute exactly simultaneously, meaning that even though the schedules
>are identical, it seems like either (in milliseconds) Job1 would execute
>before Job2, or else Job2 would execute before Job1.
>In the first case (Job1 before Job2), Job2 would stop Job1 after milliseconds
>and no trace data would hardly ever be created. In the second case (Job2
>before Job1), then Job1 does run for its five minutes before it is stopped
>and restarted. So, in the second case, this is great. So far, that appears to
>be what is happening, or at least my five minutes of trace is being collected,
>repeatedly.
>I am glad it is working like this, but it seems like it could just as easily
>have Job1 execute before Job2 and hardly any trace data be collected. What
>determines the order when schedules are identical?
sql

Job order

I have a job [job1] to start a trace and is scheduled to run every five
minutes:
Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
then...
If I have a job [job2] to stop the trace that was started in [job1] and is
scheduled to run every five minutes:
Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
I enable the jobs to run, and it appears that everything works great. Job1
executes for 5 minutes, followed by Job2 stopping the trace and doing what it
is asked to do. However, this seems to go against logic. Even though the
schedules for Job1 and Job2 are identical, it does not seem like they would
both execute exactly simultaneously, meaning that even though the schedules
are identical, it seems like either (in milliseconds) Job1 would execute
before Job2, or else Job2 would execute before Job1.
In the first case (Job1 before Job2), Job2 would stop Job1 after milliseconds
and no trace data would hardly ever be created. In the second case (Job2
before Job1), then Job1 does run for its five minutes before it is stopped
and restarted. So, in the second case, this is great. So far, that appears to
be what is happening, or at least my five minutes of trace is being collected,
repeatedly.
I am glad it is working like this, but it seems like it could just as easily
have Job1 execute before Job2 and hardly any trace data be collected. What
determines the order when schedules are identical?
--
Message posted via http://www.sqlmonster.comHi
As this would be an internal undocumented feature of SQL Server you should
not rely on this staying the same between versions, therefore you should make
sure that your jobs will behave correctly regardless, for example specifying
the duration for the trace and then you would not need to stop it.
John
"cbrichards via SQLMonster.com" wrote:
> I have a job [job1] to start a trace and is scheduled to run every five
> minutes:
> Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
> then...
> If I have a job [job2] to stop the trace that was started in [job1] and is
> scheduled to run every five minutes:
> Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
> I enable the jobs to run, and it appears that everything works great. Job1
> executes for 5 minutes, followed by Job2 stopping the trace and doing what it
> is asked to do. However, this seems to go against logic. Even though the
> schedules for Job1 and Job2 are identical, it does not seem like they would
> both execute exactly simultaneously, meaning that even though the schedules
> are identical, it seems like either (in milliseconds) Job1 would execute
> before Job2, or else Job2 would execute before Job1.
> In the first case (Job1 before Job2), Job2 would stop Job1 after milliseconds
> and no trace data would hardly ever be created. In the second case (Job2
> before Job1), then Job1 does run for its five minutes before it is stopped
> and restarted. So, in the second case, this is great. So far, that appears to
> be what is happening, or at least my five minutes of trace is being collected,
> repeatedly.
> I am glad it is working like this, but it seems like it could just as easily
> have Job1 execute before Job2 and hardly any trace data be collected. What
> determines the order when schedules are identical?
> --
> Message posted via http://www.sqlmonster.com
>|||In addition to John's comments, you could also just do this
in one job - the first job step to check if the trace is
running and stop it if it is. Then the second step is to
start the new trace.
-Sue
On Mon, 03 Apr 2006 23:31:34 GMT, "cbrichards via
SQLMonster.com" <u3288@.uwe> wrote:
>I have a job [job1] to start a trace and is scheduled to run every five
>minutes:
>Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
>then...
>If I have a job [job2] to stop the trace that was started in [job1] and is
>scheduled to run every five minutes:
>Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
>I enable the jobs to run, and it appears that everything works great. Job1
>executes for 5 minutes, followed by Job2 stopping the trace and doing what it
>is asked to do. However, this seems to go against logic. Even though the
>schedules for Job1 and Job2 are identical, it does not seem like they would
>both execute exactly simultaneously, meaning that even though the schedules
>are identical, it seems like either (in milliseconds) Job1 would execute
>before Job2, or else Job2 would execute before Job1.
>In the first case (Job1 before Job2), Job2 would stop Job1 after milliseconds
>and no trace data would hardly ever be created. In the second case (Job2
>before Job1), then Job1 does run for its five minutes before it is stopped
>and restarted. So, in the second case, this is great. So far, that appears to
>be what is happening, or at least my five minutes of trace is being collected,
>repeatedly.
>I am glad it is working like this, but it seems like it could just as easily
>have Job1 execute before Job2 and hardly any trace data be collected. What
>determines the order when schedules are identical?

Job order

I have a job [job1] to start a trace and is scheduled to run every five
minutes:
Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
then...
If I have a job [job2] to stop the trace that was started in [job1]
and is
scheduled to run every five minutes:
Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
I enable the jobs to run, and it appears that everything works great. Job1
executes for 5 minutes, followed by Job2 stopping the trace and doing what i
t
is asked to do. However, this seems to go against logic. Even though the
schedules for Job1 and Job2 are identical, it does not seem like they would
both execute exactly simultaneously, meaning that even though the schedules
are identical, it seems like either (in milliseconds) Job1 would execute
before Job2, or else Job2 would execute before Job1.
In the first case (Job1 before Job2), Job2 would stop Job1 after millisecond
s
and no trace data would hardly ever be created. In the second case (Job2
before Job1), then Job1 does run for its five minutes before it is stopped
and restarted. So, in the second case, this is great. So far, that appears t
o
be what is happening, or at least my five minutes of trace is being collecte
d,
repeatedly.
I am glad it is working like this, but it seems like it could just as easily
have Job1 execute before Job2 and hardly any trace data be collected. What
determines the order when schedules are identical?
Message posted via http://www.droptable.comHi
As this would be an internal undocumented feature of SQL Server you should
not rely on this staying the same between versions, therefore you should mak
e
sure that your jobs will behave correctly regardless, for example specifying
the duration for the trace and then you would not need to stop it.
John
"cbrichards via droptable.com" wrote:

> I have a job [job1] to start a trace and is scheduled to run every fiv
e
> minutes:
> Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
> then...
> If I have a job [job2] to stop the trace that was started in [job1
] and is
> scheduled to run every five minutes:
> Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
> I enable the jobs to run, and it appears that everything works great. Job1
> executes for 5 minutes, followed by Job2 stopping the trace and doing what
it
> is asked to do. However, this seems to go against logic. Even though the
> schedules for Job1 and Job2 are identical, it does not seem like they woul
d
> both execute exactly simultaneously, meaning that even though the schedule
s
> are identical, it seems like either (in milliseconds) Job1 would execute
> before Job2, or else Job2 would execute before Job1.
> In the first case (Job1 before Job2), Job2 would stop Job1 after milliseco
nds
> and no trace data would hardly ever be created. In the second case (Job2
> before Job1), then Job1 does run for its five minutes before it is stopped
> and restarted. So, in the second case, this is great. So far, that appears
to
> be what is happening, or at least my five minutes of trace is being collec
ted,
> repeatedly.
> I am glad it is working like this, but it seems like it could just as easi
ly
> have Job1 execute before Job2 and hardly any trace data be collected. What
> determines the order when schedules are identical?
> --
> Message posted via http://www.droptable.com
>|||In addition to John's comments, you could also just do this
in one job - the first job step to check if the trace is
running and stop it if it is. Then the second step is to
start the new trace.
-Sue
On Mon, 03 Apr 2006 23:31:34 GMT, "cbrichards via
droptable.com" <u3288@.uwe> wrote:

>I have a job [job1] to start a trace and is scheduled to run every five
>minutes:
>Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
>then...
>If I have a job [job2] to stop the trace that was started in [job1]
and is
>scheduled to run every five minutes:
>Occurs every day every 5 minute(s) between 12:00:00 AM and 11:59:59 PM.
>I enable the jobs to run, and it appears that everything works great. Job1
>executes for 5 minutes, followed by Job2 stopping the trace and doing what
it
>is asked to do. However, this seems to go against logic. Even though the
>schedules for Job1 and Job2 are identical, it does not seem like they would
>both execute exactly simultaneously, meaning that even though the schedules
>are identical, it seems like either (in milliseconds) Job1 would execute
>before Job2, or else Job2 would execute before Job1.
>In the first case (Job1 before Job2), Job2 would stop Job1 after millisecon
ds
>and no trace data would hardly ever be created. In the second case (Job2
>before Job1), then Job1 does run for its five minutes before it is stopped
>and restarted. So, in the second case, this is great. So far, that appears
to
>be what is happening, or at least my five minutes of trace is being collect
ed,
>repeatedly.
>I am glad it is working like this, but it seems like it could just as easil
y
>have Job1 execute before Job2 and hardly any trace data be collected. What
>determines the order when schedules are identical?

job listing

Hi fellas.
I need you to answer a question:
What should I do and which SQL Server tool do I have to use in order to find a job listing on the database ?
Thanks in advance,
Abraho.hi
you can view the jobs (scheduled or current activity in the enterprise manager) or in SQL Analyzer run this:

use msdb
sp_help_job

Saludos
Abel.|||or this:
select * from msdb..sysjobs

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