Wednesday, March 21, 2012

How to include SSIS into install file?

I've already read many topics that was asked about SSIS runtime, but for my purposes I didn't find satisfied answer

Our clients don't use SQL Server for their data. But we anyway used DTS packages for transfering data between client DBes. Only thing that we needed to install was DTS dlls.

What will I need to do now to use old DTS and new SSIS packages on these clients?

Can someone to help me?|||

See my reply to your post on the SSC forum

-Jamie

|||Unlike DTS, SSIS is not redistributable. You need SQL license for every machine where SSIS runs (you may develop and debug SSIS packages using just Tools install).|||

Michael Entin SSIS wrote:

Unlike DTS, SSIS is not redistributable. You need SQL license for every machine where SSIS runs (you may develop and debug SSIS packages using just Tools install).

So, Do I have to install SSIS runtime on each 500-1000 single computers of our company's clients?

And what type of license do we need for this?

Or maybe I don't understand something how it works. What we need that every user of our clients will be able to run SSIS packages to copy/backup data from Server on his own computer or remote(Server) computer itself. It depends on where this user want to see this copied data. Maybe for this puporses there is some feather of SSIS that I still don't know. Another thing - type of DBes may be diffrent on Server and on client computers.

|||

In an ideal world you would have a single package. You would loop 500 times (or however many you need) changing the connection string each time appropriately.

If you have a different RDBMS on each source system though this will probably not be possible because the metadata will most likely change. If every one of the 500 clients has the same schema on the same RDBMS then it is theoretically possible. And certainly alot easier than installing SSIS on 500 machines (and having to do it all over again when machines are upgraded).

Might I suggest you change your architecture to a proper client/server one? Have a centralised server that contains all the data and the clients connect to get their own data.

-Jamie

|||Company clients are real estate agencies. Each agency has many agents in the field who need copied DB on their computers which most of the time disconnected from the Server. So, they need the smart client on their computers. After they update data about properties they will copy updated data from their client to the Server using DTS. Usually local computer has Access DB, and MySql or MSDE (now we want instead it SQL Express) on Server. So, how exactly do we have to change architecture? More easier I think still to work with DTS and wait for distributable SSIS runtime or something like this.|||

Instead of pushing data up to the server have you considered pulling data from the clients instead?

That way the package(s) fire centrally so you only need 1 license.

-Jamie

|||

Jamie Thomson wrote:

Instead of pushing data up to the server have you considered pulling data from the clients instead?

That way the package(s) fire centrally so you only need 1 license.

Do you meen that each client will send request to Server to start pulling or pushing data on this client computer DB using SSIS or DTS packages which are located on Server itself?

May be it will be effective solution. If we don't find easier way without changing architecture to use SSIS we'll use this solution.

Thank you.

|||

Yep. That's exactly what I mean.

Strictly speaking you can't execute a SSIS package sitting on another server. There is a way around it though. You can set up a SQL Agent job on that remote server to run teh package and then execute that job from wherever you like.

-Jamie

|||

Jamie Thomson wrote:

Yep. That's exactly what I mean.

Strictly speaking you can't execute a SSIS package sitting on another server. There is a way around it though. You can set up a SQL Agent job on that remote server to run teh package and then execute that job from wherever you like.

Yes, I have already read about it. I hope we'll find something else, not so complicated as changing architecture.

But anyway thank you for your answers.

No comments:

Post a Comment