Showing posts with label job. Show all posts
Showing posts with label job. Show all posts

Monday, March 26, 2012

Packages related with its jobs...

Hi,

I have diferent jobs scheduled in the system but I cant find which Package is launched by the job. I only have this information: (double click over the job, steb tab, modify button for any job step, in the command text window)

DTSRun /~Z0x9D852D31537078274085C85BE05756CCE0CA78671EC12A 4BDFFEC4E5E6017E4841EE5F41C492CCAA7F5746CA894011BB 376479B6E679EC3C6045C328D1EF1CDA7CF28B6EEFE9DFE923 7DF5662AE09BD6215C35AA4121BD2DE4433C7BABEE42EC87E7 0F47EA7C01FB44CB28

I would like to know the Package name related to.

Any help would be very appreciated.

RegardsHi,

I have diferent jobs scheduled in the system but I cant find which Package is launched by the job. I only have this information: (double click over the job, steb tab, modify button for any job step, in the command text window)

DTSRun /~Z0x9D852D31537078274085C85BE05756CCE0CA78671EC12A 4BDFFEC4E5E6017E4841EE5F41C492CCAA7F5746CA894011BB 376479B6E679EC3C6045C328D1EF1CDA7CF28B6EEFE9DFE923 7DF5662AE09BD6215C35AA4121BD2DE4433C7BABEE42EC87E7 0F47EA7C01FB44CB28

I would like to know the Package name related to.

Any help would be very appreciated.

Regards

Try:

select * from sysdtspackages where id = '[package id]'

[edit: d'oh, I should read SQL BOL first! The /~Z is an indicator that the string that follows is encrypted. I do not know SQL's encrption algorithm so I'm afraid I can't really help here.]|||thanks. I have tested the sysdtspackages table but I cant find any useful information to relate a job with the package that is running.

Meanwhile I will try SQL BOL.

Regards|||Is the dts packagae writing a log file in the logs folder of the mssql folder? If not, modify the dts package to write the log. Then, aftter the dts packagees execute, check the log. It will hold the clear text name of the package and the results of each step in the package. You should be able to correlate the run time and the associated package. And if you have to delete old logs, the dts package will recreate them on the next execution.

Package wont run in a scheduled job

Hello,

I have put together a simple SSIS package that runs fine both via BIDS and via Mgt Studio.

The problem I have is that I can't get a scheduled job to run it. My scheduled job has only 1 step - and that step runs the package.

When I right click in Mgt Studio (SQL Agent) and choose "Start Job" I get this error :

Executed as user: NMR044BRASQL886\SYSTEM. ....3033.00 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 14:10:56 Error: 2007-01-09 14:10:56.50 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTS:Property" with error 0x8009000B "Key not valid for use in specified state.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Error: 2007-01-09 14:10:57.04 Code: 0xC0202009 Source: B2B_Sales_Territory_Send_Back Connection manager "b2b_datamart" Description: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80040E4D. An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E4D Description: "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.". End Error Error: 2007-01-09 14:10:57.04 Code: 0xC020801C... The package execution fa... The step failed.

Can anyone help please?
I'm new to SSIS so clear+simple answers appreciated.

Thanks in advance
Mgale1

Check the ProtectionLevel proeprty of your package. My guess is that it is set to EncryptSensitiveWithUserKey. Is that correct?

This means that all passwords and such are encrypted with the username of the person that built the package hence when you run it as another user (which you are attempting to do here), it doesn't work. Read in BOL about the ProtectionLevel property to get a full understanding and then reply here with any problems.

-Jamie

|||

Hi Mgale1,

This could be due to the ProtectionLevel setting for the individual packages - that's my guess.

By default, these are set to EncryptSensitiveWithUserKey. This means as long as you personally execute the packages, your credentials are picked up and the packages execute in your security context. This is true even if you're connected to a remote machine, so long as you're using the same AD credentials you used when you built the packages. Does this make sense?

When the job you created executes, it runs under the SQL Agent Service logon credentials.

My understanding of the "Sensitive" in EncryptSensitiveWithUserKey is most likely flawed, but I cannot find a way to tell my SSIS package "hey, this isn't sensitive so don't encrypt it." Although this sometimes gets in the way I like this feature because it keeps me from doing something I would likely later regret. Anyway, my point is the Sensitive label is applied to connection strings and I cannot find a way to un-apply it (and I'm cool with that).

One of the first things an SSIS package tries to do (after validation) is load up configuration file data. This uses a connection, which (you guessed it) uses your first connection string. Since yours are encrypted with your own personal SID on the domain and this is different from the SID on the account running the SQL Agent Service, the job-executed packages cannot connect to the configuration files to decrypt them.

There are a couple proper long-term solutions but the one that makes the most sense is to use the EncryptSensitiveWithPassword Package ProtectionLevel option and supply a good strong password. You will need to supply the password when you set up the job step as well, and this should allow the package to run without needing your security credentials.

Note: You will also need this password to open the packages in BIDS (or Visual Studio) from now on... there's no free lunch.

Hope this helps,

Andy

|||

You may want to check this KB article:

An SSIS package does not run when you call the SSIS package from a SQL Server Agent job step

http://support.microsoft.com/kb/918760

|||

Admin,

This topic is a good candidate for a "sticky" for the forum.

This question is asked once a day... we (the forum) could come up with a synopsis on package encryption.

|||

I always use ProtectionLevel=DontSaveSensitive. Without exception.

This actually forces you to use configurations - and that is no bad thing in my opinion.

-Jamie

Package won''t run from job

I imported my packages to SQL Server 2005.

Under Stored Packages > msdb, if I right click the package name an select "run package", the package runs fine without errors.

However if I put the same package in a job and run the job, the job fails every time and won't tell me why. It just says to check the history. This is what the history says:

Executed as user: myDomain\SQLService. The package execution failed. The step failed.

Seems like some kind of permission failure.

Any ideas, please. This permissions stuff is driving me nuts.

Here are all the permission levels that I am aware of when running a job:

1.) permissions at the package level (conn mgrs, ftp mgrs, etc)

2.) rely on SQL Server storage for roles and access control - what does even mean?

3.) job owner (sa) - how does this differ from the job step owner?

4.) job step > run as [user] (SQL Server Agent Account) - why does this require a separate owner?

5.) package > server > Log on to the server [as user] - what the heck is this?

It's maddening. For example, I have no idea what #5 means - when it (the package) is logging on to the server, WHO is it logging on as if the package is running in a job? The job owner? The job step owner? Or something entirely different?

I've asked other people here if they have any clue how all these permissions interrelate, and frankly no one knows. It's a big mystery..... sort of like the big bang. Don't ask me how I passed my MCDBA. That is another great mystery of the universe.

It's no wonder I can't get this thing to run!

Thank you, error handler, for sending me task-related error messages.

So here's the problem:

The script threw an exception: Could not find a part of the path 'o:\myFolder'.

In one of my packages, I have a script that gets file names from the network drive, o:

My other packages reference the d: drive with no problem. It's the o: drive that's having problems.

So maybe whoever is running the package doesn't have permissions to the o: drive, right?

So, getting back to my first post, who needs the permission to read the o: drive? Probably the step owner?

|||

See this classic KB that explains it:

http://support.microsoft.com/default.aspx/kb/918760

The access to o: should be granted to the user who runs the package - Agent service account or Proxy account if you use it for this job. In your case this is currently myDomain\SQLService (from "Executed as user..." message). Also, if o: is network drive, switch to using UNC path (\\server\path) as drive mapping is user-specific.

|||

So it seems the problem has to do with the fact that the SQLService domain account does not have permissions to access o:, or that I need to use a UNC path.

However, I still have some questions about how all the pkg/job permissions interrelate to each other:

1.) permissions at the package level (ole db conn mgrs, ftp mgrs, etc) - the SQLService account does not have anything to do with this, right?

2.) rely on SQL Server storage for roles and access control - what does mean? does this relate to #1 above?

3.) job owner (sa) - how does this differ from the job step owner?

5.) New Job Step > General tab > SQL Server Integration Services Package > Server: Log on to the server [Windows Authentication] - will this be the same login as the job step owner, that is, the SQLServer account?

If anyone could answer any or all of these questions, and #5 especially, I would really appreciate it!

Thanks much

|||

sadie519590 wrote:

1.) permissions at the package level (ole db conn mgrs, ftp mgrs, etc) - the SQLService account does not have anything to do with this, right?

It depends - if your connection managers are using Windows Authentication, then the account SQL Agent is running under does have an impact.

sadie519590 wrote:

2.) rely on SQL Server storage for roles and access control - what does mean? does this relate to #1 above?

Without more context, I'm not sure. My best guess is that is referring to storing packages in SQL Server rather than the file system. If you do that, it can handle access to the packages.

sadie519590 wrote:

5.) New Job Step > General tab > SQL Server Integration Services Package > Server: Log on to the server [Windows Authentication] - will this be the same login as the job step owner, that is, the SQLServer account?

Yes, unless you have set up a proxy.

|||

1.) permissions at the package level (ole db conn mgrs, ftp mgrs, etc) - the SQLService account does not have anything to do with this, right?

It depends - if your connection managers are using Windows Authentication, then the account SQL Agent is running under does have an impact.

That's because the conn mgrs will be using the SQL Agent account, right? (Because the this is job step owner?)

Thanks|||Correct.|||

sadie519590 wrote:

So it seems the problem has to do with the fact that the SQLService domain account does not have permissions to access o:, or that I need to use a UNC path.

o: is a mapped drive, correct? Mapped drives are a user-session concept. That is, when you log on, you can map drives. However, if I remote into that box and log on as well, I don't get to see your mapped drives. Service accounts, such as those that run SQL Server, SQL Server Agent, etc... don't have any clue what a mapped drive is. As soon as you log off of the box, the mapped drives go away. So yes, if you are going to use network shares, you HAVE to use UNC.|||

Yes, the unc path did solve the problem.

Thanks all.

Package won't run from job

I imported my packages to SQL Server 2005.

Under Stored Packages > msdb, if I right click the package name an select "run package", the package runs fine without errors.

However if I put the same package in a job and run the job, the job fails every time and won't tell me why. It just says to check the history. This is what the history says:

Executed as user: myDomain\SQLService. The package execution failed. The step failed.

Seems like some kind of permission failure.

Any ideas, please. This permissions stuff is driving me nuts.

Here are all the permission levels that I am aware of when running a job:

1.) permissions at the package level (conn mgrs, ftp mgrs, etc)

2.) rely on SQL Server storage for roles and access control - what does even mean?

3.) job owner (sa) - how does this differ from the job step owner?

4.) job step > run as [user] (SQL Server Agent Account) - why does this require a separate owner?

5.) package > server > Log on to the server [as user] - what the heck is this?

It's maddening. For example, I have no idea what #5 means - when it (the package) is logging on to the server, WHO is it logging on as if the package is running in a job? The job owner? The job step owner? Or something entirely different?

I've asked other people here if they have any clue how all these permissions interrelate, and frankly no one knows. It's a big mystery..... sort of like the big bang. Don't ask me how I passed my MCDBA. That is another great mystery of the universe.

It's no wonder I can't get this thing to run!

Thank you, error handler, for sending me task-related error messages.

So here's the problem:

The script threw an exception: Could not find a part of the path 'o:\myFolder'.

In one of my packages, I have a script that gets file names from the network drive, o:

My other packages reference the d: drive with no problem. It's the o: drive that's having problems.

So maybe whoever is running the package doesn't have permissions to the o: drive, right?

So, getting back to my first post, who needs the permission to read the o: drive? Probably the step owner?

|||

See this classic KB that explains it:

http://support.microsoft.com/default.aspx/kb/918760

The access to o: should be granted to the user who runs the package - Agent service account or Proxy account if you use it for this job. In your case this is currently myDomain\SQLService (from "Executed as user..." message). Also, if o: is network drive, switch to using UNC path (\\server\path) as drive mapping is user-specific.

|||

So it seems the problem has to do with the fact that the SQLService domain account does not have permissions to access o:, or that I need to use a UNC path.

However, I still have some questions about how all the pkg/job permissions interrelate to each other:

1.) permissions at the package level (ole db conn mgrs, ftp mgrs, etc) - the SQLService account does not have anything to do with this, right?

2.) rely on SQL Server storage for roles and access control - what does mean? does this relate to #1 above?

3.) job owner (sa) - how does this differ from the job step owner?

5.) New Job Step > General tab > SQL Server Integration Services Package > Server: Log on to the server [Windows Authentication] - will this be the same login as the job step owner, that is, the SQLServer account?

If anyone could answer any or all of these questions, and #5 especially, I would really appreciate it!

Thanks much

|||

sadie519590 wrote:

1.) permissions at the package level (ole db conn mgrs, ftp mgrs, etc) - the SQLService account does not have anything to do with this, right?

It depends - if your connection managers are using Windows Authentication, then the account SQL Agent is running under does have an impact.

sadie519590 wrote:

2.) rely on SQL Server storage for roles and access control - what does mean? does this relate to #1 above?

Without more context, I'm not sure. My best guess is that is referring to storing packages in SQL Server rather than the file system. If you do that, it can handle access to the packages.

sadie519590 wrote:

5.) New Job Step > General tab > SQL Server Integration Services Package > Server: Log on to the server [Windows Authentication] - will this be the same login as the job step owner, that is, the SQLServer account?

Yes, unless you have set up a proxy.

|||

1.) permissions at the package level (ole db conn mgrs, ftp mgrs, etc) - the SQLService account does not have anything to do with this, right?

It depends - if your connection managers are using Windows Authentication, then the account SQL Agent is running under does have an impact.

That's because the conn mgrs will be using the SQL Agent account, right? (Because the this is job step owner?)

Thanks|||Correct.|||

sadie519590 wrote:

So it seems the problem has to do with the fact that the SQLService domain account does not have permissions to access o:, or that I need to use a UNC path.

o: is a mapped drive, correct? Mapped drives are a user-session concept. That is, when you log on, you can map drives. However, if I remote into that box and log on as well, I don't get to see your mapped drives. Service accounts, such as those that run SQL Server, SQL Server Agent, etc... don't have any clue what a mapped drive is. As soon as you log off of the box, the mapped drives go away. So yes, if you are going to use network shares, you HAVE to use UNC.|||

Yes, the unc path did solve the problem.

Thanks all.

Package variables "disappear" from job properties

Creating a SQL Agent job to run a package works just fine. On the Step Properties, Set values tab, I can add variables and the values I want for them, no problem. The job runs just fine. If I want to go edit the values however, they're always gone.

Is there some security setting that hides the variables and their values which is on by default?

GregsListAcct wrote:

Creating a SQL Agent job to run a package works just fine. On the Step Properties, Set values tab, I can add variables and the values I want for them, no problem. The job runs just fine. If I want to go edit the values however, they're always gone.

Is there some security setting that hides the variables and their values which is on by default?

Greg,

I don't know the answer to this but regardless, you should stop using the SSIS sub-system and just call teh package usinng the command-line sub-system instead.

There is an article at wiki.sqlis.com that explains the rationale behind this but the site is down so i can't link to it. Basically you don't get any diagnostic info out of the SSIS sub-system.

-Jamie

Friday, March 23, 2012

Package Runs in 1 minutes in Visual Studio but takes 5+ (sometimes hanges) as Job

I have an SSIS package that when run from Visual Studio takes 1 minute or less to complete. When I schedule this package to run as a SQL Server job it takes 5+ and sometimes hangs complaining about buffers.

The server is a 4 way 3ghz Xeon (dual core) with 8GB ram and this was the only package running.

When I look in the log I see that the package is running and processing data, although very very very very very slowly.

Has anyone else experienced this?

Thanks for your help

Marcus

You need to identify what the differences are between the two executions. It could be network latency, utilisation of the box by other processes, the user that you're running it as....anything.

What happens when you execute the package on the Xeon using dtexec.exe rather than thru SQL Server Agent. Do you get the same?

-Jamie

|||

I don't klnow what is going on with my system. The above package has ran find since I posted this message. I'm now having issues with stored procedure that is being ran from a job.

I can run the SP from Management Studio and it completes. The CPU does spike above 90% but it completes.

When I execute the same SP from job I get the following error and ALL connections to the database are killed.

Msg 64, Sev 16, State 1: TCP Provider: The specified network name is no longer available. [SQLSTATE 08S01]
Msg 64, Sev 16, State 1: Communication link failure [SQLSTATE 08S01]
Msg 10004, Sev 16, State 1: Communication link failure [SQLSTATE 08S01]

I have taken the SQL out of the SP and tried to execute it directly from within the job and it still fails wth the same issue.

I have no idea what is going on or where to start looking.

Here is a copy of the SP that I'm trying to run from a job.... Help... I'm glad it's a Friday


CREATE PROCEDURE [dbo].[sproc_LoadData_FactMessageOpen] AS

SET NOCOUNT ON
TRUNCATE TABLE [dbo].[FactMessageOpen]

INSERT INTO [dbo].[FactMessageOpen] (

[DateID],[TimeID],[MailingID],[ProfileID],[MessageFormatID],[TransactionDateTime])
SELECT
(SELECT DateID FROM dbo.DimDate WHERE DateAK = CAST(CONVERT(varchar(10),X.TransactionDateTime,101) AS smalldatetime)) AS DateID,
(SELECT TimeID FROM DimTime WHERE Hour12 = LTRIM(SUBSTRING(CONVERT(varchar(50),X.TransactionDateTime,100),CHARINDEX(':',CONVERT(varchar(50),X.TransactionDateTime,100))-2,2)) AND Minute = SUBSTRING(CONVERT(varchar(50),X.TransactionDateTime,100),CHARINDEX(':',CONVERT(varchar(50),X.TransactionDateTime,100))+1,2) AND NoonFlag = SUBSTRING(CONVERT(varchar(50),X.TransactionDateTime,100),CHARINDEX(':',CONVERT(varchar(50),X.TransactionDateTime,100))+3,2)) AS TimeID,
(SELECT MailingID FROM dbo.DimMailing WHERE MailingAK = X.MailingAK) AS MailingID,
(SELECT ProfileID FROM dbo.DimProfile WHERE ProfileAK = X.ProfileAK) AS ProfileID,
(SELECT MessageFormatID FROM dbo.DimMessageFormat WHERE MessageFormatAK IS NULL) AS MessageFormatID,
X.TransactionDateTime
FROM
(
SELECT
ER.TEMPLATE_ID AS MailingAK,
ER.EMAIL_ADDR_ID AS ProfileAK,
MIN(ER.ACTION_DT) AS TransactionDateTime
FROM
TEST.MDB.EMAIL_RESPONSE ER
JOIN
TEST.MDB.ACTION_SUB_ACTION_LOOKUP AL
ON
ER.ACT_SUB_ID = AL.ACT_SUB_ID
WHERE
ACTION_CD = 'G'
GROUP BY
ER.TEMPLATE_ID,
ER.EMAIL_ADDR_ID
) AS X
ORDER BY
DateID,
TimeID

|||Please share your connection strings... Could it be that the user running the job (the user assigned to the SQL Server service account) doesn't have access to the remote server/database?|||90% cpu utilization seems like too much. I'm getting the impression that you haven't examined the query execution in SQL Server Profiler. Correct?|||

Hi

I actually ran the query through SQL Profiler and it didn't come back with any recommendations. I alos looked at the explain plan and every node is using an index.

does the query look poorley written?

thanks

Wednesday, March 21, 2012

Package from Package Sore does not work as Job

Dear All,

I try to run a Package which is placed in the Package Store via a job - but this does not work.

Some things about the package:
- The package evokes some warnings, because I do not use all columns from the datasource
- Package runs in BI Studio - log is written
- Package runs if startet from the Package Store - log is written
- Package Execution stopps immediately if started via job - without writting in the log

As hint - needless to say :-) - that the log provider is configured in all three spaces...
Does anybody now, if I could use the configured log provider from the package directly in the jobs _without_ doing the settings?

Other jobs - without the warnings - are running and placing there step results in the log.

Thanks in advice!

Cheers
Markus

Some info that may help-

Scheduled Packages
(http://wiki.sqlis.com/default.aspx/SQLISWiki/ScheduledPackages.html)

|||

Darren,

sorry for this late reply - you are right!
The user did not have appropriate rights on the package store folder.

cheers,
markus

Package fails when ran as a scheduled job

I have a large number of SSIS packages, which I have developed over the last few months.

Having written and tested them locally, running in VS05 etc - I have moved them to a server, stored in the MSDB database.

I am having real troubles with packages that move tables from one database to another.

I am working on a migration project, so I have several packages that move tables from the source database, into my staging database.

One package which will not run at all, basically just moves 15 tables from database A on my server to database B.

The package is essentially a few SQL tasks to create tables, then a data flow.

The data flow contains the table movements as an OLE DB source to an OLE DB destination. No intermediate processing.

In an attempt to get some meaningful logs of the reasons for failre I ran the package from the commandline with the output piped to a text file. That text file contained the following error:

Error: 2006-11-20 11:48:47.78
Code: 0xC0202009
Source: Data Flow Task Source - tblParking [1641]
Description: An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Protocol error in TDS stream".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
End Error
Error: 2006-11-20 11:48:47.78
Code: 0xC0047038
Source: Data Flow Task DTS.Pipeline
Description: The PrimeOutput method on component "Source - tblParking" (1641) returned error code 0xC0202009. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing.
End Error
Error: 2006-11-20 11:48:47.84
Code: 0xC0047021
Source: Data Flow Task DTS.Pipeline
Description: Thread "SourceThread1" has exited with error code 0xC0047038.
End Error

I've googled for most of the error messages there, and tried applying some of the things I found.

I've set the commit size on the OLE DB destination to 10k rows.

I've set the number of engine threads to 2.

The SQL Agent service is started by a domain user that has sufficient server and database roles to do what it needs - other packages run fine.

I'm really stumped here now - this package will run perfectly in visual studio, but fails when ran
as a scheduled task, and I'd really appreciate any advice or pointers

Matthew McNally wrote:

I have a large number of SSIS packages, which I have developed over the last few months.

Having written and tested them locally, running in VS05 etc - I have moved them to a server, stored in the MSDB database.

I am having real troubles with packages that move tables from one database to another.

I am working on a migration project, so I have several packages that move tables from the source database, into my staging database.

One package which will not run at all, basically just moves 15 tables from database A on my server to database B.

The package is essentially a few SQL tasks to create tables, then a data flow.

The data flow contains the table movements as an OLE DB source to an OLE DB destination. No intermediate processing.

In an attempt to get some meaningful logs of the reasons for failre I ran the package from the commandline with the output piped to a text file. That text file contained the following error:

Error: 2006-11-20 11:48:47.78
Code: 0xC0202009
Source: Data Flow Task Source - tblParking [1641]
Description: An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Protocol error in TDS stream".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
End Error
Error: 2006-11-20 11:48:47.78
Code: 0xC0047038
Source: Data Flow Task DTS.Pipeline
Description: The PrimeOutput method on component "Source - tblParking" (1641) returned error code 0xC0202009. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing.
End Error
Error: 2006-11-20 11:48:47.84
Code: 0xC0047021
Source: Data Flow Task DTS.Pipeline
Description: Thread "SourceThread1" has exited with error code 0xC0047038.
End Error

I've googled for most of the error messages there, and tried applying some of the things I found.

I've set the commit size on the OLE DB destination to 10k rows.

I've set the number of engine threads to 2.

The SQL Agent service is started by a domain user that has sufficient server and database roles to do what it needs - other packages run fine.

I'm really stumped here now - this package will run perfectly in visual studio, but fails when ran
as a scheduled task, and I'd really appreciate any advice or pointers

Every time I have received this error:

"Communication link failure".

It has been due to network connectivity isuues during the execution of my package; nothing to do with the package itself...not sure if that is always the case.

|||I dont think its a network problem Rafael

Firstly, as there should be no network traffic, as the source and target database are on the same server.

Secondly, the package will consistently fail as a scheduled task. I could run it now manually - and it would be fine. Schedule it to run 2 minutes later - and it will fail.

Actually - I only assume there is no network traffic. The server is called Llama, and my package has two data-sources, both of which are mapped to databases on Llama.

Surely this does not mean that these packages are sending data across the network to talk to the server they reside on?|||

Verify your boot.ini file on that server and make sure that there is no memory limit like using /3GB flag. That will reduce available memory to outside applications. We faced similar issues on "Communication link failure". After removing /3gb limit flag it was running fine.

Best of luck.

Veera Maganti

|||Thanks for your response Veera.

the boot.ini on this server does not have the /3gb switch

The whole boot.ini is:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003, Standard" /fastdetect /NoExecute=OptOut
|||

Well there's your problem right there. Your server is called "Llama". if you upgrade to the "Cheetah" it will run just fine.

just joking... did you try entering a password into the SSIS to encryptsensativedatawithpassword? then schedule it and enter the password in there?

|||

Hi Matthew,

I have the same error, I want to know if you can solve this problem.

Thank you for your help.

Antonio

Package fails when ran as a scheduled job

I have a large number of SSIS packages, which I have developed over the last few months.

Having written and tested them locally, running in VS05 etc - I have moved them to a server, stored in the MSDB database.

I am having real troubles with packages that move tables from one database to another.

I am working on a migration project, so I have several packages that move tables from the source database, into my staging database.

One package which will not run at all, basically just moves 15 tables from database A on my server to database B.

The package is essentially a few SQL tasks to create tables, then a data flow.

The data flow contains the table movements as an OLE DB source to an OLE DB destination. No intermediate processing.

In an attempt to get some meaningful logs of the reasons for failre I ran the package from the commandline with the output piped to a text file. That text file contained the following error:

Error: 2006-11-20 11:48:47.78
Code: 0xC0202009
Source: Data Flow Task Source - tblParking [1641]
Description: An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Protocol error in TDS stream".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
End Error
Error: 2006-11-20 11:48:47.78
Code: 0xC0047038
Source: Data Flow Task DTS.Pipeline
Description: The PrimeOutput method on component "Source - tblParking" (1641) returned error code 0xC0202009. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing.
End Error
Error: 2006-11-20 11:48:47.84
Code: 0xC0047021
Source: Data Flow Task DTS.Pipeline
Description: Thread "SourceThread1" has exited with error code 0xC0047038.
End Error

I've googled for most of the error messages there, and tried applying some of the things I found.

I've set the commit size on the OLE DB destination to 10k rows.

I've set the number of engine threads to 2.

The SQL Agent service is started by a domain user that has sufficient server and database roles to do what it needs - other packages run fine.

I'm really stumped here now - this package will run perfectly in visual studio, but fails when ran
as a scheduled task, and I'd really appreciate any advice or pointers

Matthew McNally wrote:

I have a large number of SSIS packages, which I have developed over the last few months.

Having written and tested them locally, running in VS05 etc - I have moved them to a server, stored in the MSDB database.

I am having real troubles with packages that move tables from one database to another.

I am working on a migration project, so I have several packages that move tables from the source database, into my staging database.

One package which will not run at all, basically just moves 15 tables from database A on my server to database B.

The package is essentially a few SQL tasks to create tables, then a data flow.

The data flow contains the table movements as an OLE DB source to an OLE DB destination. No intermediate processing.

In an attempt to get some meaningful logs of the reasons for failre I ran the package from the commandline with the output piped to a text file. That text file contained the following error:

Error: 2006-11-20 11:48:47.78
Code: 0xC0202009
Source: Data Flow Task Source - tblParking [1641]
Description: An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Protocol error in TDS stream".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
End Error
Error: 2006-11-20 11:48:47.78
Code: 0xC0047038
Source: Data Flow Task DTS.Pipeline
Description: The PrimeOutput method on component "Source - tblParking" (1641) returned error code 0xC0202009. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing.
End Error
Error: 2006-11-20 11:48:47.84
Code: 0xC0047021
Source: Data Flow Task DTS.Pipeline
Description: Thread "SourceThread1" has exited with error code 0xC0047038.
End Error

I've googled for most of the error messages there, and tried applying some of the things I found.

I've set the commit size on the OLE DB destination to 10k rows.

I've set the number of engine threads to 2.

The SQL Agent service is started by a domain user that has sufficient server and database roles to do what it needs - other packages run fine.

I'm really stumped here now - this package will run perfectly in visual studio, but fails when ran
as a scheduled task, and I'd really appreciate any advice or pointers

Every time I have received this error:

"Communication link failure".

It has been due to network connectivity isuues during the execution of my package; nothing to do with the package itself...not sure if that is always the case.

|||I dont think its a network problem Rafael

Firstly, as there should be no network traffic, as the source and target database are on the same server.

Secondly, the package will consistently fail as a scheduled task. I could run it now manually - and it would be fine. Schedule it to run 2 minutes later - and it will fail.

Actually - I only assume there is no network traffic. The server is called Llama, and my package has two data-sources, both of which are mapped to databases on Llama.

Surely this does not mean that these packages are sending data across the network to talk to the server they reside on?|||

Verify your boot.ini file on that server and make sure that there is no memory limit like using /3GB flag. That will reduce available memory to outside applications. We faced similar issues on "Communication link failure". After removing /3gb limit flag it was running fine.

Best of luck.

Veera Maganti

|||Thanks for your response Veera.

the boot.ini on this server does not have the /3gb switch

The whole boot.ini is:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003, Standard" /fastdetect /NoExecute=OptOut
|||

Well there's your problem right there. Your server is called "Llama". if you upgrade to the "Cheetah" it will run just fine.

just joking... did you try entering a password into the SSIS to encryptsensativedatawithpassword? then schedule it and enter the password in there?

|||

Hi Matthew,

I have the same error, I want to know if you can solve this problem.

Thank you for your help.

Antonio

Package fails when ran as a scheduled job

I have a large number of SSIS packages, which I have developed over the last few months.

Having written and tested them locally, running in VS05 etc - I have moved them to a server, stored in the MSDB database.

I am having real troubles with packages that move tables from one database to another.

I am working on a migration project, so I have several packages that move tables from the source database, into my staging database.

One package which will not run at all, basically just moves 15 tables from database A on my server to database B.

The package is essentially a few SQL tasks to create tables, then a data flow.

The data flow contains the table movements as an OLE DB source to an OLE DB destination. No intermediate processing.

In an attempt to get some meaningful logs of the reasons for failre I ran the package from the commandline with the output piped to a text file. That text file contained the following error:

Error: 2006-11-20 11:48:47.78
Code: 0xC0202009
Source: Data Flow Task Source - tblParking [1641]
Description: An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Protocol error in TDS stream".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
End Error
Error: 2006-11-20 11:48:47.78
Code: 0xC0047038
Source: Data Flow Task DTS.Pipeline
Description: The PrimeOutput method on component "Source - tblParking" (1641) returned error code 0xC0202009. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing.
End Error
Error: 2006-11-20 11:48:47.84
Code: 0xC0047021
Source: Data Flow Task DTS.Pipeline
Description: Thread "SourceThread1" has exited with error code 0xC0047038.
End Error

I've googled for most of the error messages there, and tried applying some of the things I found.

I've set the commit size on the OLE DB destination to 10k rows.

I've set the number of engine threads to 2.

The SQL Agent service is started by a domain user that has sufficient server and database roles to do what it needs - other packages run fine.

I'm really stumped here now - this package will run perfectly in visual studio, but fails when ran
as a scheduled task, and I'd really appreciate any advice or pointers

Matthew McNally wrote:

I have a large number of SSIS packages, which I have developed over the last few months.

Having written and tested them locally, running in VS05 etc - I have moved them to a server, stored in the MSDB database.

I am having real troubles with packages that move tables from one database to another.

I am working on a migration project, so I have several packages that move tables from the source database, into my staging database.

One package which will not run at all, basically just moves 15 tables from database A on my server to database B.

The package is essentially a few SQL tasks to create tables, then a data flow.

The data flow contains the table movements as an OLE DB source to an OLE DB destination. No intermediate processing.

In an attempt to get some meaningful logs of the reasons for failre I ran the package from the commandline with the output piped to a text file. That text file contained the following error:

Error: 2006-11-20 11:48:47.78
Code: 0xC0202009
Source: Data Flow Task Source - tblParking [1641]
Description: An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Protocol error in TDS stream".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Shared Memory Provider: No process is on the other end of the pipe.
".
End Error
Error: 2006-11-20 11:48:47.78
Code: 0xC0047038
Source: Data Flow Task DTS.Pipeline
Description: The PrimeOutput method on component "Source - tblParking" (1641) returned error code 0xC0202009. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing.
End Error
Error: 2006-11-20 11:48:47.84
Code: 0xC0047021
Source: Data Flow Task DTS.Pipeline
Description: Thread "SourceThread1" has exited with error code 0xC0047038.
End Error

I've googled for most of the error messages there, and tried applying some of the things I found.

I've set the commit size on the OLE DB destination to 10k rows.

I've set the number of engine threads to 2.

The SQL Agent service is started by a domain user that has sufficient server and database roles to do what it needs - other packages run fine.

I'm really stumped here now - this package will run perfectly in visual studio, but fails when ran
as a scheduled task, and I'd really appreciate any advice or pointers

Every time I have received this error:

"Communication link failure".

It has been due to network connectivity isuues during the execution of my package; nothing to do with the package itself...not sure if that is always the case.

|||I dont think its a network problem Rafael

Firstly, as there should be no network traffic, as the source and target database are on the same server.

Secondly, the package will consistently fail as a scheduled task. I could run it now manually - and it would be fine. Schedule it to run 2 minutes later - and it will fail.

Actually - I only assume there is no network traffic. The server is called Llama, and my package has two data-sources, both of which are mapped to databases on Llama.

Surely this does not mean that these packages are sending data across the network to talk to the server they reside on?
|||

Verify your boot.ini file on that server and make sure that there is no memory limit like using /3GB flag. That will reduce available memory to outside applications. We faced similar issues on "Communication link failure". After removing /3gb limit flag it was running fine.

Best of luck.

Veera Maganti

|||Thanks for your response Veera.

the boot.ini on this server does not have the /3gb switch

The whole boot.ini is:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003, Standard" /fastdetect /NoExecute=OptOut

|||

Well there's your problem right there. Your server is called "Llama". if you upgrade to the "Cheetah" it will run just fine.

just joking... did you try entering a password into the SSIS to encryptsensativedatawithpassword? then schedule it and enter the password in there?

|||

Hi Matthew,

I have the same error, I want to know if you can solve this problem.

Thank you for your help.

Antonio

Package fails to execute as a scheduled job

I've managed to get the basics coded into my package. Nothing fancy, it is all quite literally embedded inside the package. No config files, parameters, variables, etc. I've imported the package into SSIS. I can right click on the package and select Run Package. The package fires off, validates, runs through the entire process, and completes successfully. However, when I set up the package to run as a scheduled task, it fails almost immediately with the following output.

Microsoft (R) SQL Server Execute Package Utility
Version 9.00.3042.00 for 64-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

Started: 3:28:07 AM
Error: 2007-04-25 03:28:07.41
Code: 0xC0016016
Source:
Description: Failed to decrypt protected XML node "DTSStick out tongueroperty" with error 0x8009000B "Key not valid for use in specified state.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available.
End Error
Error: 2007-04-25 03:28:11.36
Code: 0xC001602A
Source: Package Connection manager "FTP Connection Manager"
Description: An error occurred in the requested FTP operation. Detailed error description: The password was not allowed
.
End Error
Error: 2007-04-25 03:28:11.36
Code: 0xC002918F
Source: Card10 FTP Task
Description: Unable to connect to FTP server using "FTP Connection Manager".
End Error
DTExec: The package execution returned DTSER_FAILURE (1).
Started: 3:28:07 AM
Finished: 3:28:11 AM
Elapsed: 4.297 seconds

Help.......

Hi Michael,

There was a discussion of a similar error message here recently. What is the ProtectionLevel property setting for the package?

Andy

|||

There is also a KB article where they describe 4 diffrent methods for schedulling the package:

An SSIS package does not run when you call the SSIS package from a SQL Server Agent job step:

http://support.microsoft.com/kb/918760

Package Execution with SQL Server Agent or DTEXEC

Hello,

I want execute package with SQL Server Agent. I create a job and I try all the solutions : my job doesn't want to work.

I success to launch the package but the execution failed.

I try the same job launching from the server : it doesn't work either.

So, I copy the command line (/FILE, /DTS or /SQL) and with DTEXEC utility it works when this command is executed on the server (on a client computer, the problem "the product level is insufficient" appears).

Why is it working with this utility and not with a job ?

I try to change every secured option (credential --> proxy --> Run as ; change the owner of the job ; etc.)

What options must be checked and modified ?

Thanks for your help !

Somewhere there will be an error, and without that I have no idea. Try using DTEXEC through a job.

Package Execution with SQL Server Agent or DTEXEC

Hello,

I want execute package with SQL Server Agent. I create a job and I try all the solutions : my job doesn't want to work.

I success to launch the package but the execution failed.

I try the same job launching from the server : it doesn't work either.

So, I copy the command line (/FILE, /DTS or /SQL) and with DTEXEC utility it works when this command is executed on the server (on a client computer, the problem "the product level is insufficient" appears).

Why is it working with this utility and not with a job ?

I try to change every secured option (credential --> proxy --> Run as ; change the owner of the job ; etc.)

What options must be checked and modified ?

Thanks for your help !

I need HELP please :)|||

We created a package which read a flat file from another server and imported it into a table. Our package would run, but the job would not.

We found that we had to change two options - one was the location of the flat file. Our package was looking at a specific directory like "J:\Import Files\file.txt". We replaced the specific drive letter with the shared directory alias \\ServerName\Alias\Import Files\file.txt.

The second change was to alter the package to "Rely on Server ..." instead of "Encrypt Sensitive With User Key".

These two changes allowed Sql Agent to run the job.

|||

Hello,

thank you for answering, I tried your solution but no effect appears.

Actually your solution enable to execute the package in a step with a job. It seems to not fail.

The package executes through DTEXEC works fine and my destination table is filled.

When I use the same command line with a job, it works but my table is still empty. No new lines from the package !

How is it possible considering I use the same command line ?

sql

Tuesday, March 20, 2012

Package execution failed but no error (SQL2005)

I made an Integration Services Package which runs well if I start it manually
(also from SQL server Management Studio).
Now I have created a new job for the SQL server agent which need to run my
package.
After starting the job, it ends after a few seconds:
"The package execution failed" is the only message there is.
I assume it has something to do with security but for the test I am logged
in as a domain administrator which has all rights to all databases.
Can someone give some clues about how to solve this?
Thanks
Two possibilities come to my mind:
1- SQL Server run under its own account; so you should check the permission
for this account on both Windows and SQL-Server side (for example, does this
account has an explicit access to the database?)
2- You are using things like a network drive (Z:\Repertory\...) instead of
an UNC file name (\\Server\Repertory\...) which are specific to the login
account and unknown to other accounts.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Frans" <Frans@.discussions.microsoft.com> wrote in message
news:6EBD9795-92BA-435C-BCC7-CFEBDC6EAF2F@.microsoft.com...
>I made an Integration Services Package which runs well if I start it
>manually
> (also from SQL server Management Studio).
> Now I have created a new job for the SQL server agent which need to run my
> package.
> After starting the job, it ends after a few seconds:
> "The package execution failed" is the only message there is.
> I assume it has something to do with security but for the test I am logged
> in as a domain administrator which has all rights to all databases.
> Can someone give some clues about how to solve this?
> Thanks

Package execution failed but no error (SQL2005)

I made an Integration Services Package which runs well if I start it manuall
y
(also from SQL server Management Studio).
Now I have created a new job for the SQL server agent which need to run my
package.
After starting the job, it ends after a few seconds:
"The package execution failed" is the only message there is.
I assume it has something to do with security but for the test I am logged
in as a domain administrator which has all rights to all databases.
Can someone give some clues about how to solve this?
ThanksTwo possibilities come to my mind:
1- SQL Server run under its own account; so you should check the permission
for this account on both Windows and SQL-Server side (for example, does this
account has an explicit access to the database?)
2- You are using things like a network drive (Z:\Repertory\...) instead of
an UNC file name (\\Server\Repertory\...) which are specific to the login
account and unknown to other accounts.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Frans" <Frans@.discussions.microsoft.com> wrote in message
news:6EBD9795-92BA-435C-BCC7-CFEBDC6EAF2F@.microsoft.com...
>I made an Integration Services Package which runs well if I start it
>manually
> (also from SQL server Management Studio).
> Now I have created a new job for the SQL server agent which need to run my
> package.
> After starting the job, it ends after a few seconds:
> "The package execution failed" is the only message there is.
> I assume it has something to do with security but for the test I am logged
> in as a domain administrator which has all rights to all databases.
> Can someone give some clues about how to solve this?
> Thanks

Package Error.

Hi everybody,

I have created a package which contains execution of a set of SQL Stored Procedures. I scheduled the job to run every morning at 7:00 AM. I am getting the following error:

Executed as user: APD-DEV-CS517\SYSTEM. The package could not be found. The step failed.

What do you think the problem is?
Thanks again.Looks to me that "the package could not be found." Have you ensured the path is correct?|||Yeah I am sure.
Let me make sure about that and wait till tomorrow morning.

Thanks though,
Murthy here

Package configuration, Parent-child packages and Job scheduling

Hi,

I've found this problem that when I change settings in my configuration file it does not automatically apply to all child packages which uses the same configuration file if run from a job in SQL Server Agent. I need to open the package and save it again from BIDS. I use one "load group" package to execute all other packages.

Is there a way from the job configuration to set a setting so the package allways will have the newest configuration?

Regards
Simon
Hi,

Seems like noone has an answer for this.

Isn't it a fundamentally important that changes in configuration files automatically apply to packages that uses them. Am I the only one with this problem?

Regards
Simon
|||I haven't observed it myself. This only occurs when you are running from the SQL Agent? Does it work properly when you run from the command line?|||

When the package is loaded it will lok at the config settings. If you aren't passing entries from the parent to the child then it will get them from the config file (where are you holding the config settings - sounds like xml?).

You seem to be suggesting the parent package gets the correct values but the child packages get old values. I've not seen a package ignore a config file - are you sure the packages are reading the correct files? Are the files on the same server (where the packages are being run)?

Opening the package and saving it again shouldn't affect the config entries unless you look at them - in which case they will be overwritten with the values in the package.

|||

Hi,

I have the same problem with configuration file being ignored when executed ssis package via sql agent job. Have you found the solution to the problem yet?

regards,

mnguyen

|||

mnguyen wrote:

Hi,

I have the same problem with configuration file being ignored when executed ssis package via sql agent job. Have you found the solution to the problem yet?

regards,

mnguyen

If the package is running with the default values, maybe it is not able to find the configuration file. Are you sure it is in an appropriate location? Have you tried explicitly setting the configuration file via the /ConfigFile switch?

|||Thanks both to NigelRivett and jwelch for your suggestions and I'm sorry that I've havn't had the time to reply.

When I return from holiday I will investegate futher...
|||

mnguyen wrote:

Hi,

I have the same problem with configuration file being ignored when executed ssis package via sql agent job. Have you found the solution to the problem yet?

regards,

mnguyen

I spoke with mnguyen offline and we determined that it was an issue with using a relative path to the configuration file.

Package configuration, Parent-child packages and Job scheduling

Hi,

I've found this problem that when I change settings in my configuration file it does not automatically apply to all child packages which uses the same configuration file if run from a job in SQL Server Agent. I need to open the package and save it again from BIDS. I use one "load group" package to execute all other packages.

Is there a way from the job configuration to set a setting so the package allways will have the newest configuration?

Regards
Simon
Hi,

Seems like noone has an answer for this.

Isn't it a fundamentally important that changes in configuration files automatically apply to packages that uses them. Am I the only one with this problem?

Regards
Simon
|||I haven't observed it myself. This only occurs when you are running from the SQL Agent? Does it work properly when you run from the command line?|||

When the package is loaded it will lok at the config settings. If you aren't passing entries from the parent to the child then it will get them from the config file (where are you holding the config settings - sounds like xml?).

You seem to be suggesting the parent package gets the correct values but the child packages get old values. I've not seen a package ignore a config file - are you sure the packages are reading the correct files? Are the files on the same server (where the packages are being run)?

Opening the package and saving it again shouldn't affect the config entries unless you look at them - in which case they will be overwritten with the values in the package.

|||

Hi,

I have the same problem with configuration file being ignored when executed ssis package via sql agent job. Have you found the solution to the problem yet?

regards,

mnguyen

|||

mnguyen wrote:

Hi,

I have the same problem with configuration file being ignored when executed ssis package via sql agent job. Have you found the solution to the problem yet?

regards,

mnguyen

If the package is running with the default values, maybe it is not able to find the configuration file. Are you sure it is in an appropriate location? Have you tried explicitly setting the configuration file via the /ConfigFile switch?

|||Thanks both to NigelRivett and jwelch for your suggestions and I'm sorry that I've havn't had the time to reply.

When I return from holiday I will investegate futher...
|||

mnguyen wrote:

Hi,

I have the same problem with configuration file being ignored when executed ssis package via sql agent job. Have you found the solution to the problem yet?

regards,

mnguyen

I spoke with mnguyen offline and we determined that it was an issue with using a relative path to the configuration file.

Package Configuration with XML file

Hi,

I have about 40 packages in my job. One of the problems that I have encoutered is that I don't know how I could use same XML dtsconfig file for all of my files. Each SSIS calls different file.

The XML dtsconfig file is a replacment for my *.ini file in sql 2000. The dtsconfig file will hold paths to all different files. Each SSIS will take different file name at a runtime.

How can I have all the files paths in one dtsconfig file - and is it even possible to do that in SSIS?

Any help greatly appreciated....Thank you,

Maria

Yes, that is very possible. Have you tried doing it? What problems are you having?

-Jamie

|||

Hi Jamie, for my first ssis package I created new XML dtsconfig file and lets say called it "common.dtsconfig". That all works fine. Then I created my second ssis and when I was doing Package configuration for it I selected "common.dtsconfig" file, it asked me if I want to re-use it and I said "YES". But by doing that I am not getting the path in the common.dtsconfig for my second ssis. So I deleted that connection within Package Configuration and added new with new xml file name. then I took this portion "<Configuration ConfiguredType="Property" Path="\Package.Connections[CustomerMasterTmpCurrency].Properties[ConnectionString]" ValueType="String">
<ConfiguredValue>C:\Inetpub\ftproot\customers.CSV</ConfiguredValue>
</Configuration>"

and copied to the common.dtsconfig, and went back to my second package configuration-> deleted that connection-> and re-added new connection that points to the common.dtsconfig file. That seems to be working fine.

However, when I deployed my 2 ssis they both got errors that the connection xxxx cannot be find. Each of them has a different connection. I went back to each of the package configuration deleted the old connection and re-added it........I still cannot edit as it gives me an error.................

There must be a better way to handle it and I hope you can help me with it.....Maria

Monday, March 12, 2012

Package "MyPackage" has been cancelled.

Hi,

I have scheduled a package "MyPackage" in a SQL Server Agent Job. It runs periodically with success.
Sometimes the package status is shown as "Cancelled" what led me to assume some coincidences.
So I took a look at the eventlog which contains the following message:
Event Type: Information
Event Source: SQLISPackage
Event Category: None
Event ID: 12290
Date: 30.01.2006
Time: 08:00:42
User: NT AUTHORITY\SYSTEM
Computer: MYSERVER
Description: Package "MyPackage" has been cancelled.

I assume that the problem occurs when a user locally logs off from the Server where the SSIS-service is running.

Why does this happen? The Service runs under the local system account and so does the SSIS Job.

Can anybody help here?
THX
FridtjofIf you think it is a user logging off the system, can you reproduce this in a controlled manner? I do not see why this should be the cause. Unfortunately I don't know why this happens either. Have you looked in the SQL Server Agent job history? have you tried adding some logging to the package and see what that shows? The CmdExec job step may give different output to the SSIS job step type, but make sure you set the job step output file.|||I have the same issue. Does anyone have a resolution?|||This is a bug in SSIS, and you've correctly identified the cause - a user logoff may cause this to the packages being executed.

We've recently got a bug report and currently testing a fix for this issue. Expect the fix in SP2 release.