Showing posts with label settings. Show all posts
Showing posts with label settings. Show all posts

Tuesday, March 20, 2012

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.

Monday, March 12, 2012

Package changes made and saved revert to prior state when package closed and re-opened

I copied and added an existing package as a new package to a project and have been having trouble with settings reverting to those for the original package after I modify and save the changes for the new package. Sometimes happens with the save itself, other times it happens when I close and re-open the package. Most cases are with connections that revert back to the original file reference, but there are also control flow and data flow elements that keep reverting back to either settings from the original package or defaults that result in the re-opened package being in error. Not sure how to get around this issue short of developing the new package from scratch which I'd rather not do since it is fairly complex. Any help anyone can provide is appreciated. Thanks.If I were you I'll try saving a copy of that problematic package in another folder. Open the original problematic package, and then do a save.

Then using a file-comparison tool like Winmerge, text-compare the original and copy packages. If they remain the same, perhaps something is totally wrong with your BI Studio.

Another thing to check is if those "reverting" properties are saved in an external XML configuration file. It is possible that for some reason that dtsconfig file has been set to readonly, hence your package picking up the original values over and over again.

Goodluck.|||

Thank you. The external XML configuration file was not set as readonly. I had a dtsconfig file that was common to all packages which a co-worker suggested may be the cause of my problem, but I'm not so sure that is the case. He also suggested disabling the use of a configuration file for the package I was having a problem with which I did, but I still have the issue of connection strings for connection definitions reverting to their original setting for the path and file name. This isn't too big a problem because at execution time I pass the actual path and file name in a user variable, but at definition time I have to always reset the path/filename.

I haven't tried the comparison option yet, but if disabling the configuration file doesn't solve my run time issues, I'll try that next. Thanks again.

|||Jeff, when you copy a package, you need to generate a new GUID for it. On the background of the control-flow, select properties. Then underneath the Identification section, select the Generate New ID option in the ID field. This should solve your problem.|||

Phil, Thank you for your help. I reset the package id as you suggested and also re-enabled package configurations and created a package specific configuration file. That seems to have solved the problem of data flow component definitions reverting to default values. However, I am still seeing some of the issues I had before - the file specification for a connection definition keeps reverting to that for the package from which the new package was copied. Am I misinterpreting how the connection definitions from one copy of a package to another work? Are they global to the two packages or are they independent copies? I thought that by creating a configuration file specific to the new package that the connection definitions would be independent of the source package.

I also get a message each time I re-open the new package that the connection string for the database connection and database datasource are not identical and need to be synchronized. I select OK to do the synchronization, but it doesn't seem to take.

Thanks again for your help. Any further insight you can provide is appreciated.

|||

Jeff-B wrote:

Phil, Thank you for your help. I reset the package id as you suggested and also re-enabled package configurations and created a package specific configuration file. That seems to have solved the problem of data flow component definitions reverting to default values. However, I am still seeing some of the issues I had before - the file specification for a connection definition keeps reverting to that for the package from which the new package was copied. Am I misinterpreting how the connection definitions from one copy of a package to another work? Are they global to the two packages or are they independent copies? I thought that by creating a configuration file specific to the new package that the connection definitions would be independent of the source package.

I also get a message each time I re-open the new package that the connection string for the database connection and database datasource are not identical and need to be synchronized. I select OK to do the synchronization, but it doesn't seem to take.

Thanks again for your help. Any further insight you can provide is appreciated.

Between the two copied packages, are you using different package config files? If you are sharing the same config file, then you'll run into the scenario you are describing.|||I had been using the same config file, but I created a new, separate config file for the new package assuming that was what I needed to do to make package specific changes to the connection definitions. When I created the new config file, I selected all the elements shown to be available (variables, connection definitions, etc.) and then began to make changes to connection defintions, but the changes don't seem to take. As soon as I do a save, the file specifications for connections revert to the settings for the original source package.|||Resolved most of my remaining issues by not using a config file. I realize that is not a proper solution, but for now it works. I need some additional work with config files before using them in my project.