I enabled package configurations using SSIS 2012, but when I execute my package through the debugger, the values are not being read from the package. I can tell by stepping through the script tasks and also I can see the values for variables do not change as they did when the config files were read in SSIS 2008. Is there something more that I need to do other than enable package configurations and point to the files?
Thanks
During migration from SSIS 2008 to SSIS 2012 there is an option checked by default that says 'ignore config files.' If you're using config files make sure to uncheck this box. This solved my problem.
Related
Using Visual Studio to build my SSIS packages. Project connections - they seem like a good idea so I'll do that instead of repeating my code....
Problem when you try to run the packages individually outside Visual Studio, say dtexec, they don't have any connection associated with them so they fail.
Do I really have to duplicate package connections for all 20 packages? Is there not a way to share a connection?
I want to be able to run each package separately/in groups as they will have a differing schedules.
I'm a developer so Visual Studio is my default goto - would SQL Server provide a better house for this?
Thanks
For non-project based connections, when you run the package, it'd take a form like
dtexec /file MyPackage.dtsx
However, for project based connections, you need to include the project in the dtexec call. Otherwise, you'll end up with missing connection errors
dtexec /package MyPackage.dtsx /project MyProject.ispac
Note: the current documentation is inaccurate as it specifies /file MyPackage.dtsx /project MyProject.ispac The /File parameter is invalid for Project deployment model solutions
I just added a new folder and several packages to TFS server from source control, and they do exist when checking from source control.
However, none of them could be found when I tried to build a Parent package and to locate those uploaded packages in SQL server. My operation is as follows:
1. Add "Execute Package Task" component, then double click to edit
2. Package Location: SQL Server;
Connection: XXXX;
Package Name: Here pops up a list of folders and package files but newly uploaded ones are not included.
"Connection" is filled correctly because old filefolders and packages (uploaded by other people) are listed in Package Name pop-up window.
So how could I configure my packages on TFS to make it shown from SQL Server package list?
P.S. I'm using Visual Studio 2008 and SQL Server 2008
You can't. As the documentation says:
The Execute Package task can run packages stored in the SQL Server
msdb database and packages stored in the file system. The task uses an
OLE DB connection manager to connect to SQL Server and a File
connection manager to access the file system.
The Execute Package task has no idea what TFS is or how to connect to it. If you really needed to do this, then you would have to write your own custom task that does know how to connect to TFS.
However I have no idea why you want to execute packages directly from TFS anyway, it's a source control system (among other things), not a package repository.
We have an issue with a file system deployment of an SSIS package on tests environnement, DTSINSTALL fails with this error : An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B) (DTSInstall). This error is displayed juste after a double click on the manifest file
We use the deployment package to setup many config parameters to avoid the end-user to do it manualy on the config file, for this raison we need to make a deployable package and can't do it just by copying manualy the package on the sile system.
This config of the tests environnement is : Microsoft SQL Server Integration Services 2008 R2 wihout the SSIS Developement Studio but the package was developed on SSIS 2008, is there any incompatibility with the two versions ?
Thanks in advance.
Regards
Finally I found the solution, the Business Intelligence Development Studio should be installed on production environnement in order to deploy the SSIS package correctly.
Ok - this is probably a silly question but what the hell.
I've created a SSIS package with configuration and a deployment manifest. When I copied this over to the server and double clicked it, the Package Wizard returned an error - that Integration Services wasn't installed - bad.
But when I did an export data task via SSMS, I noticed I could save this task as a package. When I set up a job I noticed I could actually select an SSIS package to schedule - even though SSIS is not installed(!?!) Does this mean I could just point to my earlier package and schedule that?
If so, do you only need Integration Services installed in order to install packages within SQL Server - its fine to run them from the file system?
Cheers
Here is a good article on different ways to execute a package programmatically:
http://blogs.msdn.com/b/michen/archive/2007/03/22/running-ssis-package-programmatically.aspx
I have made a SSIS package to create an XML file, which works fine in Visual Studio, but when I try to run in cmd prompt using dtexec /f "C:\OakeyCreek.dtsx" it throws an error
SSIS Package "TestOakey" failed with exit code: 1
In the package a sqltask gives resultset as XML and a script task creates the xml file.
I did some research, same package without script task run fine both studio and cmd prompt. I am suspecting problem with script task, because I have both VS2005 and VS2008 on the same machine.
Any idea how to resolve this problem ?
Exact error ms popup is ...
Registration information for this application needs to be updated.To update, log on as an administrator and run this command.
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\VSTA.exe" /HostID SSIS_ScriptTask /setup
My operating system is Vista
Note: Edited to provide the answer!
So you've set up a SQL Server Agent job, and now you can't write to the file system. This is expected behavior, since SQL Server Agent uses SQL Server credentials to launch the job, not Windows credentials. So, what you'll have to do is this:
Under the Security folder in the Database Server in SQL Server Management Studio, find the Credentials folder.
Right click Credentials and hit New Credential.
Set up the Credential as you.
Expand SQL Server Agent, and right click Proxies, and hit New Proxy.
Set up the Proxy as you, using the Credential you just created.
Enable the Proxy to have the SSIS subsystem (if it's admin, check all of them).
Go edit the step on your job that calls the SSIS package.
Change the Run As field from SQL Server Agent to the Proxy that you just set up (if you did it right, it will be the only other choice in the dropdown).
You should be good to go!
Cheers,
Eric
You are creating the package using SSIS 2005, but running it using DTEXEC from SSIS 2008 - you probably have both SSIS 2005 and 2008 installed, and DTEXEC 2008 appears first in the path.
To use DTEXEC 2005, specify full path, like
"c:\program files\Microsoft Sql Server\90\dts\binn\dtexec.exe" /f Package.dtsx
In theory, DTEXEC 2008 should also be able to run the package (it should upgrade it on the fly to SSIS 2008 format), but there might be bugs and incompatibilities between the versions. Also it seems something is wrong with script task setup in SSIS 2008. Why would not you follow the instructions in the error message: logon as administrator and (using elevated command prompt) run -
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\VSTA.exe" /HostID SSIS_ScriptTask /setup