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.
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'm slowly getting to grips with SSIS Packages and the like, but I have searched for an answer on this and I can't seem to resolve it!
I have a .dtsx which references a file name in the SQLStatementSource of the Execute SQL Task. This file name has been altered slightly and the statement has been changed to reflect this.
When the package is in SSIS, it falls over and it is still showing the old file name in the SQLStatementSource despite it being changed to the new name.
Is there somewhere else I should be looking to alter the file name to allow the job to run?
Many Thanks
Jon
I would say follow microsoft documentation for method of automating SSIS packages
https://learn.microsoft.com/en-us/sql/integration-services/packages/sql-server-agent-jobs-for-packages?view=sql-server-2017
I guess you are running packages from SSIS catalogue with file system source
Changes made to SSIS package has to be redeployed.
Import package from file system and over write on existing package.
Validate and execute package to check changes are made
Thank you all for your comments and suggestions.
With your guidance I have now managed to resolve the issue by editing and re-deploying the project / package
I have an SSIS 2014 solution in Visual Studio 2015. The solution has multiple configurations. The solution is under source control in Git. The project is set for project deployment.
The issue I'm having is that the column mapping in the destinations keep disappearing every time anybody makes a change and checks it back into Git. The disappearances do not happen in the same areas.
I have tried recreating the project, then the whole solution, but this keeps happening. I even recreated the solution and put it under a different repository in Git. This is the first time in 10+ years of working with SSIS that I've seen something like this.
So far I haven't found anything on the different search engines.
EDIT:
The sources are just regular OLE DB sources with T-SQL queries that are typed in the "SQL command text:" box. Nothing fancy.
The project has one master package with 8 child packages. That child packages are called using the "Execute Package Task." All the child packages are self-contained, so no parameters are being passed from the master package.
The disappearances do not happen in the same areas
This means that the destination columns getting unmapped, happen randomly on the data flow in any of the 8 child packages. It's different every time any of us open the packages to check on the package logic. The destinations are just OLE DB destinations. So nothing fancy here either.
So anytime anybody in the team makes changes in any of the packages, any number of the child packages will unmap columns randomly in their data flows. There's no pattern to this behavior. That's why it's so maddening.
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.
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.