Showing posts with label install. Show all posts
Showing posts with label install. Show all posts

Friday, March 23, 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.

sql

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.

Wednesday, March 7, 2012

How To Implement sql server database on the client's computer?

Hello,
I finished my vb.net application, the application uses sql server and run pretty well on my pc. Now I want to install this application on the customer's computer, and the issue I'm not sure about is, what do I need to install on the client's computer concerning the database?
Do I install SQL Server and restore the database there? how to secure the database and make sure nobody will be able to edit the data from Enterprise Manager. What if someone uninstalled SQL Server?

Please I need help in this issue since I'm a beginner.

Thanks.

Quote:

Originally Posted by Tea Maker

Hello,
I finished my vb.net application, the application uses sql server and run pretty well on my pc. Now I want to install this application on the customer's computer, and the issue I'm not sure about is, what do I need to install on the client's computer concerning the database?
Do I install SQL Server and restore the database there? how to secure the database and make sure nobody will be able to edit the data from Enterprise Manager. What if someone uninstalled SQL Server?

Please I need help in this issue since I'm a beginner.

Thanks.


You will need to install SQL Server on your customer's server (or just his/her computer if they're the only person that will be using it). As for security, you'll need to set up database users and set their permissions accordingly. Obviously you'll need to change your app to reflect the change of database location.|||

Quote:

Originally Posted by DonlonP

You will need to install SQL Server on your customer's server (or just his/her computer if they're the only person that will be using it). As for security, you'll need to set up database users and set their permissions accordingly. Obviously you'll need to change your app to reflect the change of database location.


If I set users permissions then nobody will be able to open the database? because I've tried this before, but anyone can access the database through Enterprise Manager without username and password? And what about if someone uninstalled sql server?
I'll be thanksfull if you provide me some links where I can read articles about this issue because I couldn't find any related articles.

Thanks|||

Quote:

Originally Posted by Tea Maker

If I set users permissions then nobody will be able to open the database? because I've tried this before, but anyone can access the database through Enterprise Manager without username and password? And what about if someone uninstalled sql server?
I'll be thanksfull if you provide me some links where I can read articles about this issue because I couldn't find any related articles.

Thanks


On second thoughts you don't even need to set user permissions if you install SQL Server 2000 desktop edition (which is free!) this doesn't come with enterprise manager anyway. Download from:
http://www.microsoft.com/downloads/...&displaylang=en
Obviously if someone uninstalled SQL Server then you wouldn't have a database and your app wouldn't work, and the person who uninstalled it would be a complete muppet!|||

Quote:

Originally Posted by DonlonP

On second thoughts you don't even need to set user permissions if you install SQL Server 2000 desktop edition (which is free!) this doesn't come with enterprise manager anyway. Download from:
http://www.microsoft.com/downloads/...&displaylang=en
Obviously if someone uninstalled SQL Server then you wouldn't have a database and your app wouldn't work, and the person who uninstalled it would be a complete muppet!


Wow, Thanks alot that helped me out so much.
Just one more question, How can I transfer the database from my computer to the other, do I create a backup and restore it there? and where do I place my databases.