After I've excluded a package from a project by choosing Project->Exclude From Project, how do I 're-include' it later?
I thought it was Project->Add Existing Package, but that adds a copy of the package.
It's very easy ,
if it's old version of Visual Studio like 2012 ,
just Right Click on the folder > Add > Existing Item > choose the file which has been excluded
if it's old version of Visual Studio like 2008 ,
Right Click on the folder > Add > Include in Project
According to the documentation, SSIS will copy your existing package and place the new copy into your project's folder location. However, if your package is already in this location, it is supposed to just open the package. Since you excluded the package, including it again should work fine without it making a copy of it. The thing I notice, however, is that you don't mention getting an error. Normally you would get an error if you were making a copy and it was being placed in the same location as the original. Most like either you are renaming the package during the "Add Existing Package" stage, or your package isn't in the correct location.
If your package is getting copied with a new name, I have found some indication that this might be a bug. The work-around seems to be to then delete the original and rename the new copy. It isn't pretty but it seems to be your best option.
The answer is that you cant just "include" a package. Its more of an import which makes a copy... if the package already exists it adds a (1) to the name of the package.
This is the functionality for SQL Server Business Intelligence Development Studio that comes with SQL server 2008 R2. Doesn't make much sense but Im sure they fixed that in future BIDS releases
In Visual Studio 2015, I have found that I can re-include packages by right-clicking on the project and choosing Add | Existing Item... (not Existing Package).
It makes no sense, but it works. I guess it will work the same in other versions of VS.
Related
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.
I have an existing SQL Server 2012 SSIS solution, deployed and pulling data from an external (Oracle) server each day. I need to copy all connections / variables / packages from that solution and put it in a new solution I'm writing.
Once I copy it to the new solution, I will rename each package and adjust the queries in the data flow source pull object; then save, build, deploy as a whole new solution. The old one will not change or go away. I'm just trying to use the project/solution itself as a template, pulling variable/logging/metadata that's not as easily by opening a package.
Is this doable? I don't see many answers doing a quick Google search. Forgive me if this is a duplicate question, unclear or easier than it appears.
In Visual Studio click on your project and select the "Add existing package" from the context menu. This makes a copy of the dtsx file, and leaves the original intact. Then you can make edits to your new copy.
I have a fresh installation of Visual Studio 2015 Pro Update 2 + SSDT (June 2016).
When I attempt to edit C# code of my SSSIS script component (clicking on Edit Script...), VSTA does open without any warning/error but does not display anything (like if VSTA was called without specifying a solution to open).
However I can see the temporary solution is properly created in the background in a subfolder of folder:
C:\Users\XXX\AppData\Local\Temp\Vsta\SSIS_SC130...
I can even manually open the solution directly from this folder without any problem.
Any idea why the solution does not automatically open in VSTA ?
This occurred to me twice while working in the same environment as you and I hope the outcome for you is different.
The first time:
As for me it was that VS had corrupted the Script Component and too bad so sad I couldn't restore it.
The Second Time:
Moving the project from machine to machine, at some point there was a change to the .Net assembly of the project. Setting that back to 4.5 allowed me to view my scripts again.
Good luck and enjoy the little surprises VS and SSIS combo like to throw at you
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.
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).