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
Related
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.
I'm running into this issue basically:
Can I deploy & Use SSIS SQL server DTS DLL's onto a machine that does not have SQL server 2008 installed?
Since it's been answered I don't know if my request for further information will get any traction.
I'm running into the same problem I think. When I deploy locally on my dev box, my application calling SSIS works fine. When I deploy my application on Server A, and my SSIS package on Server B (my database server), I get the error mentioned in the post: " An Integration Services class cannot be found. Make sure that Integration Services is correctly installed on the computer that is running the application. Also, make sure that the 64-bit version of Integration Services is installed if you are running a 64-bit application".
If I understand things correctly I need to have an SSIS license on my application Server and my database server?
This doesn't seem to make sense. When you make a SQL call to SQL server, provided you have an enterprise license you only pay once. You don't have to pay for an extra license for your application server.
I just want to make sure I've got this clear before I go to the higher ups, and that my problem isn't stemming from something else. So to put it concisely: Do you need to have an SSIS license for both your app server and your SQL Server when calling an SSIS package remotely?
Just to clarify the 64 vs 32 bit thing: I've got 64 bit OS's running on my local machine, the app server and the database server - and all my VS projects are being built to use "Any CPU".
Sorry for the lengthy post, but I thought I should be thorough on this.
You will need to have SSIS licensed (SQL Server) on any machine that is using SSIS to execute packages.
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
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