I have created an SSIS package which uses a for each loop container and an Excel connection string that I have created from a variable so I can loop through multiple files. My package works without issue and if I have a number of files in my source folder and I simply execute the package it works perfectly looping through all the files doing what I want it to do.
The issue I have is when I deploy the package, If I have files within my source folder it executes without error but when you look at the source folder it still has the files in. When digging a bit deeper in to the package reports it looks like it is reporting that there were no files found. If I manually execute the dtsx file in runs without issue and imports everything as it should.
Is there any reason why after deploying the package it is unable to recognise the files or the variable that I store the file name in?
Sounds like it could be permissions related. Does the SQL Server Service account have permissions to the directory where the files are stored?
Related
I’m setting up an automated build in VSTS that will FTP the published files to my server.
I have this working but the way I’ve achieved it, I feel is hacky and non-sustainable.
the process as you can see from the screenshots will publish the artefact which consists of a readme, cmd file and a zip containing all my publish files and then I extract the ZIP with the very explicit location below.
$(Build.ArtifactStagingDirectory)\temp\Content\d_C\a\1\s\IntermittentBug\IntermittentBug\obj\Release_EukHosts\Package\PackageTmp
I’m using a hosted build server in VSTS but as the path contains
d_C\a\1\s\
I assume this will change in time. What I need is a variable to cater for this path so it will always succeed.
How can I update this to make it more efficient and sustainable?
First, as jessehouwing said that the variable is called Build.SourcesDirectory.
Regarding the path structure, the simple way is specifying /p:PackageTempRootDir="" msbuild argument in Visual Studio Build task to remove the source path structure, then the path will be like Content\D_C\PackageTmp.
On the other hand, you also can publish the web app through File System mode.
This variable is caught in a predefined variable called Build.SourcesDirectory. see the complete list of predefined variables here.
In your batch or powershell scripts this variable is available as a environment variable called %BUILD_SOURCESDIRECTORY% / $env:BUILD_SOURCESDIRECTORY.
Hi I have an SSIS package in which i have a main package that references child packages, is there a way I can make the location path external using a Relative path or just the file name. I cant use the full C: drive path as this is subject to change.
yes, but you have to find a way of changing the current working directory of the execution of the package. I worked at one place where we ran bat files to execute the packages and the first line used cd to set the working directory to the folder location of the parent package. I think I've also seen people use a script task inside the parent package to set the working directory based on the runtime location of the parent package.
http://www.artisconsulting.com/blogs/greggalloway/2008/7/13/relative-paths-in-ssis
from what i found it is best to use the project reference system instead of file reference and you can reference any project file if you deploy to the SSISDB instead of the MSDB, it works much better than the MSDB as well as being able to work with package params easier
I have defined SSIS package configuration to XML and configure it for 50 packages. The xml path for those packages were
H:\SomFolder\Configuration\XMLConfig
but in production server we don't have H: so I have created a folder on D:
D:\Configuration\XMLConfig
How can I change all packages to now refer to new path without opening each and every package and manually configure them?
You have hard-coded the xml config file path in each package and relative folder path of files is same for each package as per my understanding. Simple way is to loop through each ".dtsx" file (SSIS package) and find the string DTS:ConfigurationString="H:\SomFolder\Configuration\XMLConfig and replace it with DTS:ConfigurationString="D:\Configuration\XMLConfig with some simple program. Then, you can open the project\s having these SSIS packages and save it which will be ready to deploy on production.
This is general problem people face while developing the SSIS packages. Better way to avoid this issue is to store the xml file location in environment variable, so that you can keep the config files on different location on different machines and environment variable with same name will be present on those machines with different file location.
I am trying to zip the contents of a Folder in SSIS, there are files and folders in the source folder and I need to zip them all individually. I can get the files to zip fine my problem is the folders.
I have to use 7.zip to create the zipped packages.
Can anyone point me to a good tutorial. I haven't been able to implement any of the samples that I have found.
Thanks
This is how I have configured it.
Its easy to configure but the trick is in constructing the Arguments. Though you see the Arguments as static in the screenshot, its actually coming from a variable and that variable is set in the Arguments expression of Execute Process Task.
I presume you will have this Execute Process task in a For Each File Ennumerator with Traverse SubFolders checked.
Once you have this basic setup in place, all you need to do is work on building the arguments to do the zipping, how you want them. A good place to find all the command line arguments is here.
Finally, the only issue I ran into was not providing a working directory in the command line arguments for 7zip. The package used to run fine on my dev environment but used to fail when running on the server via a SQL job. This was because 7zip didn't have access to the 'Temp' folder on the SQL Server, which it uses by default as the 'working directory'. I got round this problem by specifying the 'working directory as follows at the end of the command line arguments, using the -ws switch:
For e.g:
a -t7z DestinationFile.7z SourceFile -wS:YourTempDirectoryToWhichTheSQLAgentHasRights
I am New to SSIS config side. I have created one package with its config file. My Project placed into my account folder at server. but I created the config file which I placed at shared drive folder and also copy the mypackage.dtsx file into another shared folder.
Now I have ran the package with dtexec.exe /f "mypackage.dtsx" without using config file even though it successfully run.
even I have changed some of the property into the config file and ran the package with use of the dtexec.exe command(mentioned above) and it was executed successfully.
So I have a question that, Do I need the config file at dtexec.exe command line because I can run my package by "dtexec.exe /f "mypackage.dtsx" " too?
I saw the syntax of dtexec.exe /f "package.dtsx" /config "myconfig.dtsconfig"
Please guide me...Does the package contains the config file and its changes?
The package will remember it's saved settings. The benefit of a config file is that if you need to override/shange the settings that are contained in it, you can do that without needing to open, fix, and redeploy your package. A config file is not ever necessary, it is just a convenience to you the developer, especially if your environment has a strict change management policy. It is usually easier to change values in a config than to edit and redeploy a package under strict change managment.
CLARIFICATION
It appears from your question that you may be thinking that when you change the config it will change your package regardless of including your config in your execution. All of the information from the config will be in the package at the time you save it, but it may differ from what is in the config. If you run without config, you are running exactly what is saved in the package. Package executions work like this:
Load package with all configurations from the saved .dtsx file
Check for configurations to load.
Load configuration in memory and overwrite values loaded from .dtsx package.
Execute.
This is simplified, and there are other things going on, but at the basic level this is accurate.