Roy,

Adding delimiters would also work, but I prefer this approach because it allows the use of name-value pairs in Attributes. I use it for a lot of things, like storing information about backups along with the backups (in Description).

--
Fernando Dias
[Team Elevate]

Fernando Dias,

Yes, that is what I had in mind, leaving the job if it is not running on the correct server.

Then it occurred to me that if you don't like all of these jobs starting up and exiting immediately because it is running on the wrong server, a "Supervisor/Maintenance" job could be created and run occasionally to disable the jobs that are not suppose to run on the current server. This prevents the jobs from even starting up. Neat, eh? This is like a belt and suspenders type of solution to the problem.

Barry

Barry,

Yeah, awesome idea. Depending on the circumstances, it might even be appropriate to delete the JOBs that are not needed in each server instead of disabling them. It would be perfect if we could schedule JOBs to run at server startup. Something like:

CREATE JOB SuperJob
RUN AS "System"
FROM DATE '2013-01-01' TO DATE '9999-12-31'
AT SERVER START
....
 

--
Fernando Dias
[Team Elevate]

Fernando Dias,

>Yeah, awesome idea. Depending on the circumstances, it might even be appropriate to delete the JOBs that are not needed in each server instead of disabling them. It would be perfect if we could schedule JOBs to run at server startup. Something like<

But that assumes the job attributes never change.

What happens if you change the attribute of a job so it should now run on the current server? You would have to restart the server to get it to enable the job. Same with disabling a job.

I would run the Job Supervisor job once a day or every 6 hours depending on how frequently the job attribute gets updated. It would be nice if there was a Before Update/Insert trigger for jobs so the job could be enabled/disabled automatically in the trigger by examining the current server name, but alas, there are no triggers for jobs.

BTW, can Jobs be included in replication? If so, then a central database can control all of the server jobs by updating the job attributes at the central location which in turn tells if the remote server is allowed to run the job when the replication data finally arrives on the remote server. Neat.

Barry

Barry,

<< But that assumes the job attributes never change. >
Yes, thats why I said "Depending on the circumstances, it might even be appropriate ...".

<< BTW, can Jobs be included in replication?>>
No. JOBs are stored in the configuration file that is not replicated.

--
Fernando Dias
[Team Elevate]

Thanks Barry, Roy and Fernando for your collective wisdom on all this.

I think I have a handle on what I have to do and possibly also how I can do
it.  The proof will come over the next couple of months when I have to
actually implement all this!

Thanks again

Jeff
--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz