Recently i was given a task to upgrade SSIS packages from 2005 to 2012. They were not even on source control nor did they added packages to VS solution.
So i started with creating new VS solution and project. When i tried to organize packages into folder i couldn't find a way to create directories?
So my question is, is it possible to create directories for the SSIS packages?
AFAIK this is not supported. I would use projects or Solution Configurations.
Related
I need to understand what a certain job in SQL Server 2012 does. It's a job someone created and left the company before I started to work here, and nobody on my team knows what this job does also.
The job isn't SQL command based but SSIS Package (which I'm not familiar with), the package points to a Maintenance Plan with the same name as the job. As I read on the internet I connected via Integration Services type, then Stored Packages -> MSDB -> Maintenance Plans, right click on the Maintenance Plan and exported it to a .dtsx file.
I opened it in Visual Studio 2010 Shell, but I can't edit anything because of this error:
The task with the name "" and the creation name "" is not registered for use on this computer.
I also don't have a Solution Explorer for that package, and the icons of the tasks seem a bit faded compared to tasks icons of a new project if I create one.
Maybe the dated version of the VS can be the problem? Perhaps there is other way to see what this job does?
I never worked with SSIS before so maybe I'm missing something very basic but I've been on the Internet for days already and can't find any solution.
Please help,
Thanks in advance
By way of background, until Visual Studio 2019, VS, by itself, couldn't open an SSIS package.
Prior to VS 2010, you needed to use a different product, called Business Intelligence Design Studio (BIDS), which was based on VS, but was built for SQL Server functionality. With the release of SQL Server 2012, Microsoft created SQL Server Data Tools (SSDT) as a plugin for VS that required a separate installation. Until SSDT(VS) 2017, you needed to have stand-alone versions of BIDS or SSDT for each version of SSIS you were working with in your environment. The 2017 version, though, is backward compatible to SQL Server 2012, and forward compatible (!) to SQL Server 2019. Visual Studio 2019 has SQL Server Data Tools sort of built in, but you need to add extensions through the extension manager for SQL Server Integration Services (SSIS), Analysis Services (SSAS), and/or Reporting Services (SSRS).
That's kind of a lot to take in, and is sort of irrelevant to you, but it forms the context for Larnu's comments. Rather than messing around with antique versions of Visual Studio, you should just install either VS2017 and also SSDT, or VS2019 with the SSIS extension. Both are in current widespread use, so support is easy to find, and either will allow you to work with the 2012 package you're trying to open up.
Once you have the software installed, you should be able to create a "dummy" integration services solution that you can use to open random packages. I keep one around called MiscSolution. Right click on the solution name, select Add -> Existing Item. Then find your .dtsx package and import it. (Or right click SSIS Packages -> Add Existing Package. I always do it at the Solution level because that interface allows you to select multiple packages.)
Note that when you do this, you're making a new copy of the package in your local solution directory. You are NOT working on the copy of the package that sits in the folder where you picked it up. This matters if you're going to be making any changes, since it will need to be redeployed. It also matters if you accidentally hose up the package, because you've done no harm as long as you just delete that copy.
Once the package imports, which might take a minute or so depending on how complex it is, you should be able to open it up and see what's going on.
Working on a project to migrate SSIS 2008 projects to 2016 deployed to a File Server. Currently have the packages on the file server and prefer to keep it that way. I'm aware that the Project Deployment Model has been introduced since 2012.
Questions:
Can I change the migrated projects to Project Deployment Model and still deploy to the File System? Is changing to a Project Deployment Model a best practice?
Researching online, I can only find tutorials on how to deploy to SSISDB(Catalogue). Is the deployment to a File System still the same as previous versions ie. Build project > SSIS creates manfest file in project directory > open the manifest file to deploy?
Well, it is possible with certain limitations.
First, let's state that "deploying to File System" usually means that you store your package on a file system folder, and run it with dtexec. In that sense, deploy SSIS Project to File System is certainly possible, you can run any package from project file. For more details and examples - see MS Docs on dtexec.
However, this is not practical. By doing so, you loose a significant part of SSIS functionality introduced in 2012 version. For example, execution reports in SSIS Catalogue, and project environments which allow fine control and management of package parameters, including encryption of sensitive data like passwords. SSIS Catalogue keeps versions of deployed packages, so you can roll back to previous version easily.
Besides, SSIS Catalogue is fully supported in SSMS; on running package from project file - you are on your own to supply parameters; connection strings are usually passed from environments.
Yes, it's possible but not recommended (and not always possible). Package deployment model exists for backward compatibility. Once you convert your packages to Project Deployment Model you should deploy only to the SSISDB catalog on an instance of SQL Server.
Project Deployment Model contains packages, parameters, Connection managers and more very cool features introduced in 2012. This is the best option to work with SSIS these days.
https://learn.microsoft.com/en-us/sql/integration-services/packages/deploy-integration-services-ssis-projects-and-packages
I have seen some answers to this problem already, but I am in need of a dummies guide to how this is done.
We have a overcome some obstacles already and are now at the point where I am trying to get the resultant package deployed. What I am trying to master is how to create a nuget package so that our Octopus Deploy system can then deploy it to our various platforms.
I have seen this article PowerShell for SSIS deployment and maintenance that was inside this article Updating Deployed SSIS Package and is a great script for using PowerShell to deploy, but I need this to be run from TFS as a build step. From this, I am hoping to be able to generate a nuget package.
Is this possible?
If my understanding is correct, you are trying to create NuGet packages during your TFS build.
To achieve this, you need to add the NuGet Packager task. Check this link: https://www.visualstudio.com/en-us/get-started/package/build/team-build
Is it possible to keep the all of my database scripts in VS? Is there an easy way or would I have to create the scripts from the database and manually add that file into my VS project?
Yes, in fact recent versions of Visual Studio have a type of project just for this - Database Projects
There's also SQL Server Database Tools (SSDT), which is kind of the same idea, but its own package if you don't have a version of VS that supports it on its own. I believe SSDT has been superseded by Database Projects in VS.
I have completed my Project in VB.Net and has published my project.
But i want to come out of these things
I have Sql Server Database in my project and i want my setup to add that database to sql server on installing my project.
I want my application to automatically detect sql server 2008 r2 and if it is not instaled i want it to install for me and then atach the database.
I dont want to add the database as a Attached database in my project.
i dont want to install crystal report in my application.
I have some unused refernces in my application in my project which i want to removed, i have tried the default visual studio remove unused references but still have some references like shockwave.dll log2net.dll etc.
The first step would be to switch to an MSI-based installer. This should allow you to resolve issues 3 and 5 (you control what the MSI includes). You can use a Visual Studio setup project, WiX or a commercial setup authoring tool.
For installing your database (issue 1), the best approach depends on how you use your database. Some installers simply copy the database files, others install it using custom actions and others execute SQL scripts. You should first determine how you want to install it and then ask a more specific question if you encounter problems.
To install SQL Server when it's not found (issue 2), you can use a prerequisite. This is done differently for each setup tool, so you first need to decide on a tool and then research how it supports prerequisites.
For issue 4, I'm not sure I know what to say. An MSI package will install what you include in it. If you don't add Crystal Reports in your package, then it won't be installed.
Visit
http://www.codeproject.com/Articles/10032/Deploy-SQL-Server-databases-easily-with-an-Install
Deploy SQL Server databases easily with an Installer class
Best regards!
Elias Sant Anna