Leo Peysakhovich (6/20/2012)
Agreed with SSC-Enthusiastic. This solution is very danger to implement. Especially in environments where multiple DBAs and database developers controlling jobs in a heavy processing environment. If for some reason error email is missed (or action is not taken because users are not complaining) the price will be very heavy for missing the next run. E.g. if I can use pliers to hit the nail it does not mean that this is right tools for the job. So, I would like to know why this solution was implemented.
Your example is most relevant, specifically, i don't need a crane to nail two 2x4's together either.
I'm pretty sure that the idea of 'universal solutions'/one size fits all is a myth. While it may not be the pathway you want to use in large installations, most SQL instances are not, and thus might have a place.
as to 'missing' emails, we have more than one recipient as a backup, and i did state that this does not remove responsibility for not only paying attention to your emails, but also to any job failures on your system (per post above). One OR the other should prompt you to do something about the problem/failure. Also failure notification would be immediate, giving you some time to determine what caused the issue and resolve it, long before it would be 'due'.
The only thing that changed with this implementation, was the jobs self schedule instead requiring some sort of manual kick off.
and as to why, succinctly:
This is a scheduling 'addon' to handle cases where the native scheduling isn't as flexible as is necessary to the specific varying periodicity of this type of data load.
i seemed to have rebutted his issues to his satisfaction, with just a minor request for further background information. what part did i miss with you?