February 29, 2008 at 6:46 am
I'm a new user on a very small system, and all environments will run against the same database on the same server.
I'm managing my environments manually, by having the same folder structure under DEV, TEST and PROD folders.
I've built a small job consisting of a parent package with 3 child packages and an input and output spreadsheet. Locations for the child packages and the files are by way of parent package variables, and a config xml file controls the parent variables.
I've deployed the job in the File System, in a sub folder called DEV, and set it up on a SQL Server Agent job. It is running OK.
I then copied the packages, manifest and config file from my development area to my production area, and deployed them into the PROD folder of the file system. The deployment went ok and I changed the paths in the config file during the process.
I set this up on a different schedule and it ran ok, but the output file is still going to the dev area, so it doesn't look as if it is using the config file.
I was given some advice to remove the default values from the SSIS packages, but as soon as I save or build them the system puts them right back in.
Another site suggested the package was looking for the config file where it was at design time, so I renamed it to test this, but it still worked (tho putting the file in the wrong place).
I can't use environment variables because prod, test and dev are in the same place.
Any new ideas would be greatly appreciated
TIA
February 29, 2008 at 7:06 am
Did you check your connection manager for the destination? Sometimes it is just simple things like this. See if that is pointing to your destination correctly.
[font="Verdana"]Imagination is more important than knowledge-Albert Einstein[/font]
February 29, 2008 at 7:33 am
The Excel Connection is defined as variable XLDestination, which is populated from a parent package variable called XLOutput. XLOutput is assembled from 2 separate variables that are both set in the Config file for the parent package.
Another variable is the path for the child packages. If I move the packages from DEV instead of just copying them, the job will fail, because it is ignoring the config file.
And yet, if I look at the XML behind the parent package in PROD, I can see that it is referring to the config file that gives it the correct parameters. The scheduled job also shows the correct files:
/FILE "E:\Program Files\Microsoft SQL Server\90\DTS\Packages\PROD\TTR Analysis\TTRParentPackage.dtsx" /DECRYPT /CONFIGFILE "E:\Program Files\Microsoft SQL Server\90\DTS\Packages\PROD\TTR Analysis\TTRParentPackageConfig.dtsConfig" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING E
I can only think it is because all the values used in testing are being saved with the package when it is built, and it isn't looking at the config file because it already has the values. I don't know how to remove the values without actually amending the packages once they have been signed off into production, which is not acceptable
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply