![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 11 to 16 of 16 total |
![]() |
Thu, May 1 2014 7:58 AM | Permanent Link |
Fernando Dias ![]() | 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] |
Thu, May 1 2014 11:51 AM | Permanent Link |
Barry | 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 |
Thu, May 1 2014 5:36 PM | Permanent Link |
Fernando Dias ![]() | 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] |
Thu, May 1 2014 9:59 PM | Permanent Link |
Barry | 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 |
Thu, May 1 2014 10:28 PM | Permanent Link |
Fernando Dias ![]() | 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] |
Wed, May 14 2014 12:17 AM | Permanent Link |
Jeff Cook Aspect Systems Ltd | 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 |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |