June 1, 2011 at 11:39 am
Can anyone please tell me what steps I have to follow to schedule a package in remote Sql Server 2008 after development has done in BIDS. I'm new to SSIS.
Currently the solution is in my local machine and in default location. i.e;
C:\Documents and Settings\test\My Documents\Visual Studio 2008\projects
June 2, 2011 at 2:10 am
you mean deploy to production?
June 2, 2011 at 7:18 am
I developed package in my local machine 'A' using BIDS which was installed with Sql Server 2008 R2.
My database is on another machine which is server 'B'.
Now I want to schedule my package to run at particular time.
Usually we will connect to sql server through Management studio right. So, Can I connect to server 'B' through Management studio from my local machine and create a job for the package which is in my local machine default location or Do I need to copy my package files to server 'B' and then schedule a package. Since I'm using 'File System' as a package source.
To schedule a package do I need to deploy it or should I enable package configurations ?
June 2, 2011 at 10:35 am
Lets start with some practices..
You should NEVER be trying to run production packages from your development machine like this.
Regardless of whether you are using the file system of the SQL server to store your packages for SSIS to use it should be at a location that is designated for production or for whatever level it is at. That location should not be a development machine unless the SSIS server is the development SSIS server.
Once you have the packages in a place on the FS where SSIS knows about them you can schedule them through SQL Agent. By default in SQL 2008 (and R2) the file system location for the SSIS packages will be:
C:\Program Files\Microsoft SQL Server\100\DTS\Packages
I recommend adding directories so that you can specify what each package is tied to. But then again I don't usually use the file system to store the packages.
Your question about deploying or package connections shows a misunderstanding.
When you deploy a package you are putting it somewhere else, presumably with the purpose of running it from the server.
Package configurations are just that, configurations, they affect the way a package runs but changing run-time values. It is not uncommon to have several different configuration files that make the subtle changes required as a package moves from development through QA to production. With the goal being the package is NEVER changed once it leaves the developers hands.
Not sure if all that helped..
CEWII
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply