Compress files using SSIS Process Task - ssis

I am trying to zip excel files using SSIS Process Task. This task asks for Executable. Unfortunately on the machine where I am executing SSIS, does not have any 3rd party provided compression utility. All I have is Windows built in compressor. I want to know how this can be used as executable and zip my files.
Thank you for your time.

You could use 7zip's command line version without installing it.
http://www.7-zip.org/download.html
Also, if your excel files are outputed as '.xlsx' they are already compressed. This is also true for any other office type that ends in an 'x'. Try changing the extension to '.zip' and open them.
Edit: Depending on how much you're doing you might want to consider buying the Cozyroc package which includes a zip task as well as many other useful ones. Not too costly either.
http://cozyroc.com/

I just want to add this note about cozyroc
You can test and develop with the SSIS+ components for as long as needed to determine if the components are suitable for your needs.
When you run the SSIS package from the command line with DTEXEC or SQL Server Agent, the license verification code is activated.
If a license is not found, the package execution will fail, the first time it tries to use SSIS+ library component.

Related

Is there an automation tool to convert BIML to SSIS Package?

I have hundreds of BIML scripts and I have to convert each into SSIS package. The only process I figured out is to manually right click the biml file and convert it click the Generate SSIS Package. (Please follow the link to visualize it). How do I automate this process. In other words, how can I programmatically convert all the biml scripts into their corresponding SSIS packages..
https://www.google.com/url?sa=i&url=http%3A%2F%2Fwww.erikhudzik.com%2Ftag%2Fssis%2F&psig=AOvVaw3vHH8scEdHu5w-JUDrHyLi&ust=1657797254349000&source=images&cd=vfe&ved=0CAkQjRxqFwoTCLDFmZfe9fgCFQAAAAAdAAAAABAR
You should be able to select multiple files, right click and generate them all at the same time.
You can also reference one biml script from another. So you can have your main entry point which contains a <packages> element and then reference other scripts within that which define each package.
Finally, if you have biml studio, this comes with a command line utility which would allow you to do it programmatically.
There are 3 tools for transforming Biml into DTSX packages: BimlExpress, BimlStudio (formerly known as Mist) and the precursor to BimlExpress - BidsHelper. That product no longer exists and the Biml bits in it and has been rebranded.
Under the covers, BimlStudio is going to invoke Bimlc.exe which is the Biml Compiler and that is how scripts become packages. Buy it outright or rent it monthly, depending on your needs. This is your only choice for unattended/automatic/automated builds.
BimlExpress is the free tool that can also transform scripts into packages. It requires mouse clicks to build packages.
The big difference between the two, for the beginner at least, is convenience. I have ScriptedPackageA and ScriptedTablesB which makes Package1. In BimlStudio, I can set the properties so that one is live (tables) and just evaluate/expand the Package script. In BimlExpress, I need to shift/control click the scripts I want to be compiled/referenced.
Also if you have hundreds of Biml scripts... you might not have understood the idea behind Biml. For reference, I have about about 7000 .biml files on my machine but I bet I have less than 30 describing package patterns. The only way I'm at my large number of Biml files is that I have scripted a number of databases with an file per table.
Generally speaking, you want to distill your approach down to distinct patterns and then throw your metadata against it. How many ways can you have a package that loads from file to database?

I have a production SSIS project and I need to change the destination server. Can I just edit the project or do I need to repackage it?

I have a production SSIS project in SQL Server 2016 that creates and exports a flat file to another server. The destination server has reached end-of-life and I need to change the destination path to the new server so we can decommission the old server. Can I just edit the package or project in Visual Studio or do I need to recompile (redeploy? republish?)? I have never edited before, only created new projects however that was a few years ago and I am a little rusty.
Alternatively, I could copy the existing job, edit the copy, then run them in parallel first. Then I can disable the old project/package once I am confident the new one works. I'm not having much luck figuring out how to do this either.
Any help would be appreciated. Thanks!
If I'm understanding your question correctly, it sounds like your goal is to simply change the destination location for your report. You would need to update the connection manager for your flat file connection inside of your SSIS package.
You would need to edit your flat file connection manager's connection string (by loading up the connection manager properties and changing the value yourself or by changing the expressions, if it is parameterized). Once you have verified it is now pointing at the right server's location to save the report you are generating, you would rebuild the entire package and redeploy it, which would essentially overwrite the .ispac and .dtsx files on the deployment server with your updates.
Standard caveat of "it depends" but the most common case is that you can solve this through Configuration.
Right click on the Package (or Project) depending on how things are set up. In the "Connection Managers" tab, find the connection manager that corresponds to the flat file output (a strong naming standard helps). I have selected SO_61794511.dtsx and the Name is Flat File Conn... which then allows the right side menu to be populated.
Of interest here is ConnectionString. I am going to directly edit this to change from C:\ssisdata\input\so_61794511.txt to my new path D:\path\here\something\so_newthing.txt
Click OK 2x and the next time the package runs, it will use the configured value.
That's the easiest approach. You could accomplish a similar thing if you edit the job that runs the package to set the value at every execution but this just does it at a global scale.
Where this can go off the rails is if there's a expression applied to the ConnectionString property, e.g. the output file has a dynamic date in the file name. This is why I advocate for exposing Package or Project level parameters of a "base file path" concept. This allows me to change the path from C: (local development) to D: (server deployment) or even to a UNC path \server\share by setting a configuration instead of hard coding a path into the packages themselves.

File Watcher Job Using SSIS

I am using SSIS for ETL and I need to monitor a source folder for the source file to be arrived. When ever a file arrives I need to move that file into another location and rename the file and start executing another SSIS Package. Here we don't have an option to use use any other tool to automate the execution. We have only choice to use SQL Server, SSIS.
I need the mechanism and the logic to implement this logic.
I'm assuming that by "File Watcher" you don't mean FileSystemWatcher class in .NET, as there wouldn't be any point in using this class if you're limited to SQL Server and SSIS (you'd need a job with forever-running SSIS package containing ScriptTask with FileSystemWatcher).
The only solution is to create two-step job. First step would contain SSIS package for reading directory content and comparing it to files history log. Second step would contain your main package and would execute only if first steps succeeds or returns value indicating that there are new files to process.
Your answer is here and here. My personal favorite way of doing it is having an infinite loop package. Yet another way of doing it would be to encapsulate the entire logic in an SSIS package and fire it every X minutes. Vary the value of X depending on the urgency.

Recover a SSIS project from a SSIS package

I was developing a SSIS project, but accidentaly, I erased it. However I keep a copy of the SSIS package. So my question is, it is posible recover the project using the package? or is someway to read the package content to start over the project?
Thanks
I don't remember there being anything too essential stored in the project files for SSIS projects - you can create a new project and then 'Add Existing Item...' and add the package(s).
#Will gave you the correct solution. Project files are XML files that list which packages are part of a project. You can add an existing package back without any issues. You can even manually add a node if you want by editing the file directly. I use to find this useful before BIDS Helper offered sorting capabilities.
You may also want to implement a version control system if you are working with SSIS. Every once in a blue moon a package gets into a funky, unrecoverable state and we have to rollback to a previous version to get it working again. This happens about 4 times a year for a team of 6 people who work on 100-200 packages. Also, you will never lose a package again even if you erase it on the server and your local copy is wiped out.

How to create a MS Word document using SSIS package?

Using Script Task, I have written a code to create a folder and create a MS Word document inside the newly created folder. It is working on the local machine but it is not working on the server where the package is deployed to. The folder is created successfully, but the Word document file is not created. For Word document creation, I had to refer another DLL where I had included an additional namespace Microsoft.Office.Interop.Word. Is there anything else to do before deployment ?
Based upon rfonn's comments, your choices are as follows:
Install Word 2007 on the server.
Re-do your package on a dev box with Word 2003 installed and deploy to your server.
Use some other tool to generate the Word Document.
SSIS is generally used for movement of data, so while it is possible to do what you are doing, it is likely not the best tool for the job. If you are capable of writing code in a script task to do what you want in SSIS, it is possible to write a program (VB or C# or any other tool you choose) to do the same thing without SSIS being wrapped around it. My money is on option #3 being your best choice.
I guess you missed installing the Office PIA.
After installing the relevent PIA according to your Office version, add a reference to microsoft.office.interop.word (.NET) file in your project (ssis script in VS).