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.
Related
I am using VS 2017 SSDT 15.9.20 to create an SSIS package. The package is originally created in Server A where SSDT is installed and the SQL server resides in Server A. So I was ale to create the package in Server A. I created a SQL job in Server A and linked directly to run the DTSX file without deploying it.
What my package does:
In server A my package will read the excel in the location C:\Users\xxx\Documents\myproj\excelfile.xls
and will create excel sheets inside C:\Users\xxx\Documents\myproj\files\ folder.
Deployment:
Now I want to deploy this package to Server B. And my package will read the excel in the location \ServerB\S:\Documents\myproj\excelfile.xls
and will create excel sheets inside \ServerB\S:\Documents\myproj\files\ folder.
My questions:
Should I deploy my project to create dtsx file? There is already a dtsx file inside my project folder. Can I not just move that file to server B and change the connection string and paths? Will it work that way?
SSIS deployent tool does not work for me from server A. It does not identify the destination servers.How can be deployment made easy? How can I change the destination paths?
Server A has both SSDT installed and SQL database resides in same server. But the target server B is a database server and does not have SSDT in it. I will schedule a job in SQL server of server B that will call my dtsx package and execute it.
I am new to SSIS. so please don't close this question and would be great if anyone can help me with these questions. Thanks!
Without knowing the version of SQL, I'll give both answers:
Should I deploy my project to create dtsx file? There is already a
dtsx file inside my project folder. Can I not just move that file to
server B and change the connection string and paths? Will it work
that way?
Versions less than SQL 2012: Copy the dtsx file from your project to the folder on the target server. Connection strings can be change in the configuration of the SQL Agent job or by using package Configurations:
https://learn.microsoft.com/en-us/sql/integration-services/lesson-5-add-ssis-package-configurations-for-the-package-deployment-model?view=sql-server-ver15
Versions greater SQL 2012: Create the ssis catalog on the target servers:
https://learn.microsoft.com/en-us/sql/integration-services/create-the-ssis-catalog?view=sql-server-2014.
Right click on the project and use the wizard to deploy to the target server. Connection strings can be modified in SQL Agent as noted above, or you can use parameters:
https://learn.microsoft.com/en-us/sql/integration-services/lesson-6-using-parameters-with-the-project-deployment-model-in-ssis?view=sql-server-ver15
The latter my seem like more work at first, but there is a myriad of benefits and it is the preferred way of doing things
SSIS deployent tool does not work for me from server A. It does not
identify the destination servers.How can be deployment made easy?
How can I change the destination paths?
Follow either deployment method noted above. Package deployment (copy files to a folder) still works in later versions, but it is less easy to manage and less things done for you like securing configurations and setting up logging.
Server A has both SSDT installed and SQL database resides in same
server. But the target server B is a database server and does not
have SSDT in it. I will schedule a job in SQL server of server B
that will call my dtsx package and execute it.
SSDT has no bearing on SSIS, but Integration Services does. SSDT is a developer tool and really should only be installed on developers machines for the purpose of creating packages and testing. It is better to not have this on the server because it encourages development to happen there and for devs to logon to the server like it's their laptop. Integration Services is a service that comes with SQL Server and is used for executing packages. You'll need to add this service to the instance if you want to execute packages from SQL Agent. This link explains that and gives guidance on installing SSDT locally:
https://learn.microsoft.com/en-us/sql/integration-services/install-windows/install-integration-services?view=sql-server-ver15
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).
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/
I am trying to connect to a MYSQL database using VB.NET to handle some simple tasks at a page level. Usually the connections are made to a MYSQL database. I have downloaded a MYSQL-CONNECTOR 6.0.7. How do I reference or add this to my web project so that I can create the connection and use the provided methods?
In the unzipped package I download I do not see any dll files so not sure what to do with this ATM, I am used to seeing a bin folder which contains this. Maybe I have a bad download any suggestions?
If you downloaded the ZIP archive, then generally this is the source code distribution. You need to open MySQLClient.sln in Visual Studio and build the MySql.Data project to produce MySql.Data.dll in the bin folder.
the last version is 6.4.3 download from http://www.mysql.com/downloads/connector/net/ , add reference for the unzip folder and us it as sqlClient it has the same class only have to append My to the class name