When I ran a package directly on the machine with sql 2005 installed it ran at a fine speed. But when I used Remote Desktop to access the same client and run the same package it was much slower.
1. I think that the package is running in the memory\cpu of the local machine. Is this correct
2. Is there any way for the remote client to run the package in the server's memory\cpu
TIA,
barkingdog

Where is the package running?
zaynun hammoud
wrade
musicandstamps
For execution location, it does not matter where the package is stored, what is important is where the program that runs it (usually DtExec) is located.
Airan
The slowdown might be due to delay caused by all the graphics I/O in BIDS which is slower due to network latency caused by remote desktop connection. BIDS does cause some overhead due to debugging output and tracing; when measuring package performance it is better to use DTEXEC.EXE.
myDisplayName
isn't it also true that web services or .NET remoting can be used to remotely run a package stored in the file system on a remote server
sashisme
I would like to get a clarification on your explanation.
Let's say I have ServerA, ServerB and WorkstationC. I'm using the "SQL Server Management Studio - SQL Server Import and Export Wizard" in WorkstationC to copy a few million rows in multiple tables from ServerA to ServerB. I noticed that while the process is running, the network traffic & processor usage in WorkstationC is close to 100%.
1. Does this mean that all data goes from ServerA to WorkstationC to ServerB
2. If the answer to the previous question is yes, is there another way to do this Import/Export without having to use a Remote Connection
SandpointGuy
robrich
I used Windows Remote Desktop to go to my workstation (with sql 2005 and SSIS installed). Then I created a new package in BIDS (using the remote client), selected the Start (green triangle) option of BIDS, and let er rip.
The remote client does not have sql 2005 or VS.NET installed on it has limited RAM.
Barkingdog
Marek Zgadzaj
Sun_Shine
1. Yes, the package runs on the same machine where you run the wizard.
2. You may save the package to a file or SQL server, then create an Agent Job on either ServerA or ServerB that will run this package and start the job. Then the package will run on machine where you've create the job.