I have an SSIS package that contains a connection manager used for logging. The logging service has been deprecated and I have been tasked with removing references to it from the package. Before I delete the connection manager, I need to remove all references to it, but I haven't been able to figure out how to do that. Can anyone give me any advice? The target server of the package is SQL SERVER 2012, and I am editing the package with Visual Studio 2017.
You would likely spend more time in analysis than just killing the connection manager and following the error list as your clean up punchlist.
Have package in source control
Delete connection manager
Close and reopen package and find and address all instances that show as broken.
Run package as there may be places (Script Task/Components come to mind) that might not know they're broken
Commit to source control.
Lather, rinse, repeat for all packages.
If you need to provide a list beforehand, you could reverse engineer the package to Biml and then you'd have a much smaller domain of XML to sift through looking for references to your connection manager.
Related
I have an SSIS package deployed to an SQL Server by Project deployment model.
When I configure to use that package as a job step, I see that there are other connections that this package does not use at all (they are all project-scope connections). I tried to look in the SSMS as well as to google but got no luck to find a way to remove these unused connections. Please advise. I can not remove these project-scope connections because they are used by some other packages in the SSIS project.
If you deploy with the project deployment model, you inherit those connection managers. If you don't want them in your package, you could:
Put your package in another project;
Convert the project connection managers to package-scope for the other packages.
But you can't have your package as part of a project, without the connection managers of that project.
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 am modifying an SSIS project that our company took over from another vendor. I can see that for the existing projects, when I change the solution configuration, all the OLEDB connection server names are changed. Specifically, if I change the solution configuration from "production" to "staging", all the connections change from production server to staging server.
I can't figure out how this is done. I've been searching MSDN, Google, etc. for some time, and all the posts point me to the package configuration, but that is not what the project is doing, because all the existing packages have the option "Enable package configurations" turned off.
Does anyone have any ideas? Any help will be very much appreciated!
From your description I think you are seeing Visual Studio Configurations at work. These can store a discrete version of each Data Source's connection string definition (in the .dwproj file). Visual Studio magically swaps these in and out as you change the Configuration selection.
This is not related to the package configuration, which will actually override whatever you see in the Visual Studio UI at runtime. This can be very confusing.
I have installed SSIS for VS2012 (SQL Server 2012) and I am able to create basic packages that run, however I am unable to get any of the logging to work. I have configured logging for text files and for the SQL Provider however, neither will log the execution of the package which is just a few SQL statements. I have configured all of the events to log in the details and in the advanced selections. The exec SQL tasks are in a Data Flow container, which I have also enabled logging.
When I look for the table msdb.dbo.sysssislog it is there but it is empty. If I configure the file writer, it will not create a file, which I specified to be in \windows\temp to avoid any permission problems.
If you deploy your packages to SSIS Catalog, you can have access to a better logging system that is offered by SSIS2012. You can Right-Click on your project under Integration Services Catalog and Report All Executions. This is highly recommended and makes your DBA's life much easier. you can learn more about how to set this up here.
Ok - this is probably a silly question but what the hell.
I've created a SSIS package with configuration and a deployment manifest. When I copied this over to the server and double clicked it, the Package Wizard returned an error - that Integration Services wasn't installed - bad.
But when I did an export data task via SSMS, I noticed I could save this task as a package. When I set up a job I noticed I could actually select an SSIS package to schedule - even though SSIS is not installed(!?!) Does this mean I could just point to my earlier package and schedule that?
If so, do you only need Integration Services installed in order to install packages within SQL Server - its fine to run them from the file system?
Cheers
Here is a good article on different ways to execute a package programmatically:
http://blogs.msdn.com/b/michen/archive/2007/03/22/running-ssis-package-programmatically.aspx