David McKinney (4/29/2013)
Interesting idea...but the article has a somewhat incomplete feel to it.I notice that you never get beyond the 'Introduction' heading.
A little more explanation - perhaps a working example...and more importantly a conclusion (does it work? is it a good idea? is there a risk?) would have been welcome.
I was wondering how you make it known to others how these jobs are getting into the job list. If everyone "just knows" about the metadata table that creates jobs, then perhaps I'm being pedantic. However, if/when a new DBA sees self-deleting jobs appearing and disappearing (before doing the exhaustive task of identifying the metadata table and the SP that consumes it) there may be some confusion. Also, is this cause for a security concern? Can a jr.dev add schedule entries to the metadata table via an insert right and bypass any security on scheduled job creation? Whose credentials are these jobs running under?
fwiw - i was expecting to read an article about problems/solutions involving parallel execution and scheduled jobs. Something along the line of "T-SQL with a singleton usage expectation got scheduled twice... it took {too long} to find/fix the deadlocks that were killing performance."