I have an SSIS file created using the Import and Export wizard. Using that wizard seems to hard-code the connection string into the SSIS file; what I'd like to do is pass the connection string into the file so that I can configure the target database. Anybody know how to do this?
edit A little more info: Technically I've got 17 SSIS packages that I am executing from a PowerShell script using dtexec. I'd like the PowerShell script/dtexec to be able to pass the connection string into each SSIS package. I created these packages using the SQL Server Import/Export wizard.
Assuming the package is in C:\ssis, your connection manager is named MyConnectionManager, this will override the the value and point it to localhost.
dtexec /file C:\ssis\pkg1.dtsx /conn "MyConnectionManager";"\"Data Source=localhost\TestSQL2008R2;Initial Catalog=ConnDB;Integrated Security=SSPI;\""
The sample provides the best simple solution to promote the SSIS across environment. Refer the below blog by Rafael Salas to understand more options.
Understanding Integration Services Package Configurations
You can also use graphic shell of dtexecui to configure parameters of package. This UI has a tab "Command line", where you can find all parameters, converted to command string, which you can use as parameter to console dtexec.
You can get step-by-step example here http://sqlstudies.com/2013/07/31/using-dtexecui-to-generate-a-dtexec-command-line-statement-the-easy-way/
Related
I have a fairly simple control flow with two data flows. The first one reads data from an Excel spreadsheet using a source script component and stores data into a cache transform component. The second data flow uses a source script component to read a text file, then uses a lookup component to verify that the text file contained the correct information. The No match output from the Lookup is written into a flat file destination. If I run the package in Visual Studio, either debugger or execute, everything works. If I try to run the package from the command line using dtexec.exe I get the following error.
Description: The component is missing, not registered, not
upgradeable, or missing required interfaces. The contact information
for this component is "Cache Transform;Microsoft Corporation;
Microsoft SQL Server; (C) Microsoft Corporation; All Rights Reserved;
http://www.microsoft.com/sql/support;1".
Other packages that don't use a Lookup component give a different error.
Description: To run a SSIS package outside of SQL Server Data Tools
you must install Enterprise Edition (64-bit) of Integration Services
or higher.
I'm using Visual Studio 2015 and SSIS 2016, and the project target server version is SQL Server 2016. I'm running dtexec.exe from C:\Program Files\Microsoft SQL Server\130\DTS\Binn\. Running dtexec.exe from c:\Program Files (x86)\...\DTS\Binn\ gives the same result.
Try repairing / reinstalling SSIS per your comment:
Integration services are installed but I can't find SQL Server
Integration Services on the services list. Something must have gone
wrong in the installation.
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 need to export packages deployed in SSISDB by any means to make it automated; so a command line, C# or T-SQL would be fine. I don't want the manual way used by Visual Studio. Thanks
I finally got it. Use stored procedure in SSISDB "catalog.get_project" which will return project_stream. Save it to a file with ".zip" extension and extract the packages from it.
This is because as per Microsoft documentation the ISPAC file is based on OPC standard which is genuinely was invented by Microsoft and used for pptx, docx ... etc.
IsDeploymentWizard is a good option. You can see parameter usage by typing
IsDeploymentWizard -h
on the command line.
I have an application I am writing that accepts files of various formats. Then I write code for each format (csv, excel, xml) to convert it and enter it into a SQL Server database. This is fine but I was just looking into SSIS and wondering if this would help.
The main question though is how do I run these packages within my own code? Is it easy to pass parameters? If I move this web app to another server does it depend on other components being on that server (maybe SQL Server 2012 installed)? Or is it just some DLLs I can reference from my web app?
All the demos I see are about using the SSIS tool but I am more interested in how difficult it is to call packages with parameters from my code.
The BIDS/SSDT installation includes a complete client SDK that makes it pretty simple to run SSIS packages via code.
This MSDN article explains how to load and run a package via C# in detail but the actual code boils down to:
using Microsoft.SqlServer.Dts.Runtime;
.
.
.
Application app = new Application();
Package pkg = app.LoadPackage(PKG_FILE_NAME, null);
DTSExecResult pkgResults = pkg.Execute();
The Package object has a lot of properties and methods you can look into, in particular there is a Parameters collection that allows you to pass parameters into your SSIS package before execution.
There is a very cool library called EzAPI where you can generate your own packages and call them from within C#. It gives you a lot of flexibility to generate SSIS on the fly and execute.
http://sqlsrvintegrationsrv.codeplex.com/releases/view/21238
I built a couple console apps inside this project to test some of these methods and you might find the examples useful:
https://github.com/thevinnie/SyncDatabases
Look at "BuildingAPackage" and "BuildALookupPackage"
You can programmatically build SSIS packages using C# or VB.NET and then run the packages. You can also load an existing package programmatically to execute it. I have little experience with building packages this way since most of the packages can be built easily using the following tools.
Read the article Building Packages Programmatically on MSDN for more details.
I feel that it is easier to build the packages through these IDEs depending on which version of SSIS you are targeting. You can also create initial packages through SQL Server Import and Export Wizard and save the SSIS packages to the local disk, which you can later modify according to your needs.
SSIS Version Development IDE Visual Studio Shell
------------------- ----------------------------------------------- -------------------
SSIS 2005 Business Intelligence Development Studio (BIDS) Visual Studio 2005
SSIS 2008 - 2008 R2 Business Intelligence Development Studio (BIDS) Visual Studio 2008
SSIS 2012 SQL Server Data Tools (SSDT) Visual Studio 2010
You need to reference the appropriate SSIS specific DLLs in your code to create/load SSIS packages.
However, you will need a SQL Server Integration Services license to run the package. You cannot simply reference the DLLs alone. The license is usually part of your SQL Server license, if you already have one.
Response to your comment:
We will have SQL 2012 or 2008R2 on a separate server.. So I just need to paste the needed DLLs on my web server and reference them. correct ?
The packages will execute on that server. You are just remotely invoking to execute them and you should reference the appropriate DLLs in the code within your web/other form of external application. I usually schedule the packages to run on the database servers under SQL Server Agent Job. You can try that if that is an option for you.
Package parameters are read-only from an external application. You'll need to pass them in as variables (which I have done). If you are dealing with an existing package with parameters, you may consider writing a script task that populates the parameters from the variables (which I have not done).
Does anyone know how to Unzip password protected files in an SSIS package?
We have an SSIS package that currently use java.util.zip to unzip zip file and has been working perfectly for some time now. They now want to password protect the files and unfortunetly this library cannot do it.
We are using a SQL server 2008 with .Net 3.5 on the windows server 2008 R2.
I have enjoyed using DotNetZip, it's free, has rich functionality and is well documented
DotNetZip
examples of using it in SSIS
You would have to write a C# script that has the password and you would be able to unzip it using the built in .Net library.
Use an execute process task and call winzip, IZArc or similar program you can drive from the command line. Use the expressions properties to dynamically set paths and passwords for the command line
PragmaticWorks have a "TF Compression Task" in their Task Factory suite which handles password protected zip files very nicely. You'll need to buy a sever license to use their suite in production, but you can download and use it free within VS2008 BIDS.
I've got a licensed copy of Task Factory and would recommend it to anyone who uses SSIS in a corporate environment.