Coming back with a question about the GAC and SSIS.
My colleagues developped two external DLL's for their SSIS packages. I'm trying to see how it can be added to the server without being added in the GAC.
Why? Just because I prefer to keep my installation the cleaner as possible and this instance is located on a cluster so, when there is an update (or something else), the maintenance is not really easy.
Best way for me is to put these DLL's on a network shared drive where they can be accessed by SSIS. Is it possible to act like this?
Thanks!
PS: I'm working with SSIS & SQL Server 2012 on a Windows Server 2008R2 64bits
The only approach I've seen used to avoid pushing things into the GAC, but still use it from within SSIS, is to roll that DLL into a service, web or windows, and then change your code to use those service methods.
The other thought is if there isn't actual code reuse for these DLLs, just have them inline them into the package. You can add classes to the Script Tasks and Component, they're just C#/VB.NET projects.
Related
is there a way to directly modify a package in the ssis catalog?
What I'm trying to achieve is "source control" building something like a main repository for me and all other developers. We need more visibility on the packages being built. i.e., when you pull into your own machines and not keep the development on the server, we don’t see what is being done.
You probably want to use version control such as git or Team Foundation Server / Visual Studio Team Services. Using the deployed package as version control is bad practice and might risk breaking it or making it unrecoverable.
Use a VCS, git and VSTS are free.
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.
On my development machine I have Visual Studio 2010 and SQL Server 2008 Express. On our production server we have SQL Server 2008 Standard. I am going to create a WCF service that will reside on the production SQL server that will fire my SSIS package when called.
Because I have SQL Express on my development machine, I do not have access to create SSIS packages from this machine at all. This is needed so I can write the WCF service in the first place.
So, I could simply download SQL Server 2008 Standard from our msdn subscription to my development machine, but for reasons I cannot get into, this is not immediately possible. It will be in the near future but not soon enough.
How can I get this done? Are there tools to download? Where? I have researched this at length but there appears to be 5 different ways that lead to no where.
Since you have a licensed Edition of SQL Server on your network you can install the full suite of tools on your development server or your own desktop if you wish. This will give you access to BIDS software that SliverNinja mentioned.
I would say since you are limited to what can be done you only option would be to deploy a simple/basic package to your production server. If your development server can communicate with that server, I would say create your WCF service on the development box and have it simply call the package on your production server. The package does not have to do anything fancy to simply verify that you can call it correctly. Just have the package import a simple file and output it to a different file; or just export some catalog data from a database.
I do not see, since you are limited by not being able to duplicate your production environment on your dev server, that this would be unreasonable to do in this situation. If it has to get done, it has to get done.
So you want to create a package without BIDS?
Feel free to create one using plain text, there you go :)
<DTS:Executable xmlns:DTS="www.microsoft.com/SqlServer/Dts" DTS:ExecutableType="MSDTS.Package.1">
<DTS:Property DTS:Name="PackageFormatVersion">2</DTS:Property>
<DTS:Property DTS:Name="CreationDate" DTS:DataType="7">5/18/2012 1:21:47 PM</DTS:Property>
<DTS:Property DTS:Name="ProtectionLevel">1</DTS:Property>
<DTS:Property DTS:Name="DisableEventHandlers">0</DTS:Property>
.....a lot more properties.....
</DTS:Executable>
I'm joking, of course. My points are:
dtsx packages are merely XML files created by BIDS
you can create your package anywere, if you cant use your local box,
use what you have, even if that means to use your server (if that's
your only option, do it)
you dont need BIDS or even the SSIS service to run pacakges. DTEXEC,
DTEXECUI and SQl Server Agent are capable of running packages by
themselves (unless the packages are deployed to the package store)
I am not aware of any tool that builds packages other than BIDS. It
wouldn't make much sense, is like asking if there is a tool where you
can build C# application other than visual studio
You need BIDS (Business Intelligence Development Studio) to create the DTSX packages and SSIS which isn't available with SQL Express.
You also need Visual Studio to create WCF services, which it sounds like you already have.
On this link 2nd workaround method suggests to try running SSIS package on computer that doesn't have SQL instance. How is that possible? Do I need to have installed VS 2008 Business Intelligence or it's possible even without it?
I found a link that may help you. Read this MSDN article.
This article has answers for your questions:
"You can install SQL Server Integration Services on a computer that has no previous instances of SQL Server."
"The Business Intelligence Development Tools (BIDS) option installs the Integration Services components required to design a package, but the Integration Services service is not installed and you cannot run packages outside of BI Development Studio."
Of couse the only install the latter is not enough to run arbitary packages.
The following may help you:
Install dtexec utility on the webserver or wherever your SSIS package resides. Regarding the minimum requirements please check this page: http://msdn.microsoft.com/en-us/library/ms162810.aspx
Create a .cmd/bat file that calls dtexec including all the needed parameters. Your webpage 's button or a scheduled job will trigger this .cmd or .bat file
Now, to stop a package in this setup, you can use a precedence constraint for example a file, you can check if the file exists before executing each next step in your SSIS package, this approach is discussed here: http://www.dotnetspider.com/forum/250123-Stop-SSIS-package-at-runtime.aspx. By the way to stop the package I thus suggest creating a second button.
You can install SQL Server Data Tools (SSDT) without installing SQL Server by itself, and then you can use integration services. Try this link:
https://learn.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt?view=sql-server-2017
I've seen this link about running an SSIS package in a C#/.Net application on someone's box who doesn't have SSIS installed.
I thought I'd ask if since that article has been published if there's another way to allow an end user to run an SSIS package on their box without having SSIS intalled. I'd hoped that my C# application's reference to the Microsoft.SqlServer.Dts.Runtime assembly would do the trick, but that's just not the case.
It would be easier at my work to have the users install SSIS than try the workaround mentioned in the article, whereby a windows service on a 3rd box does most of the work. But I thought I'd check if there'd been any breakthroughs on doing this. Thanks!
You need to have SSIS installed on the machine in order to use the API. I do not think you want to do that because Microsoft wants you to have a SQL Server license for every machine that has SSIS installation, even without the SQL Server part. This will get expensive real quick. I think your idea of having an Agent Server that runs the packages on request will work best.
HTH