Job on Prod Server using Dev Server resources after migrating packages

[bittmapp]

I created several packages on DEVSERVER and migrated files to PRODSERVER. I created a job on DEVSERVER and then modified the job script to create the same job on PRODSERVER. When I schedule the job on PRODSERVER it seems that there is some connection to the DEVSERVER that is using up its resources. Shouldn't the sqlsvr.exe process be running on the PRODSERVER? I DID schedule the PROD job from SQL Management Console on the DEVSERVER. Does that have something to do with it? The PRODSERVER does not have the Management Console on it so I cannot create or schedule the job directly from the PRODSERVER. Do I need to do this in order to leave the DEVSERVER out of it completely? ANY input would be greatly appreciated.
Thanks in advance.
-bitt

 

[gradley]

Are you sure you didn't hard code your connections in the SSIS package to your DEVSERVER. They shoud be soft coded using Config files.

 

[bittmapp]

Thanks for your response. I have checked all, I mean all of the connections in all of the packages and they all point to the PRODSERVER databases. Do you think I should install the SQL Management Studio on the PRODSERVER and create the job and schedule from there? thanks so much.

 

[gradley]

So if I understand you correctly, you have your production server registered on your development machine but are scheduling the Sql Server agent job on the production server not the development server? If this is true, it shouldn't matter as long as didn't leave the "Server" property for the job as "(Local)" or the Development server name.

Did you use the "Script Job As" option from the job to create a script file to load it to the production server?

 

[bittmapp]

Gradly, thanks so much for your replies, I will re-script the job as you suggest and see if it changes the behavior. I initially scripted the job to a "New Query window" and changed all of the instances of DEVSERVER to PRODSERVER. I thought that would work. I will let you knwo how it goes. Thanks again! -bitt