sqlAgent - Quit without running downstream job-Steps

  • Hi,

    I  have a scenario, in which there are 5 interdependent job-steps in my sqlAgent job. (Step x+1  depends on the success of Step x)

    My requirement is to let the header job-step to have the capability to give a Go/No-go to the downstream job-steps on a need-basis.   If the header job-step decides that it is not appropriate day/time for the downstream to execute, then, it should be able to mark the entire sqlAgent job "success" without letting the downstream dependent job-steps to run.

    Basically, my header job-step decides the appropriateness of the entire job-stream to run or go to sleep based on a config table.

    Please let me know if/how this scenario is achievable in sqlAgent.

    thanks

  • etl2016 - Tuesday, February 6, 2018 3:26 PM

    Hi,

    I  have a scenario, in which there are 5 interdependent job-steps in my sqlAgent job. (Step x+1  depends on the success of Step x)

    My requirement is to let the header job-step to have the capability to give a Go/No-go to the downstream job-steps on a need-basis.   If the header job-step decides that it is not appropriate day/time for the downstream to execute, then, it should be able to mark the entire sqlAgent job "success" without letting the downstream dependent job-steps to run.

    Basically, my header job-step decides the appropriateness of the entire job-stream to run or go to sleep based on a config table.

    Please let me know if/how this scenario is achievable in sqlAgent.

    thanks

    You can control the flow of things like that where you go to the next step on success and then on failure go to some last job step of just a print statement so it shows up in the history. And the second to the last step before that would be on success quit job reporting success, on failure, fail job. So you only get to the last step when your condition check is no go.
    That's usually what you see for things with conditional job steps and you can use similar things to skip steps.

    You may want to consider two different jobs though. The first job being the condition check, your Go/NoGo in an if statement. if the condition is true, use sp_start_job to start the job that has the steps with the processing. If false, print 'Not okay to run at this date/time'.
    That gives you a better idea on when and how often the processing job runs without having to check the specific steps when it's all in one job. And allows the first job to report a failure when it fails outside of your check for Go/NoGo if that's the case (table dropped, login failed, timeouts)

    Sue

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply