That still does not resolve the issue of someone having a job_id parked in some code somewhere and that job_id ceasing to exist when a job is dropped and recreated
Very true, but that's up to the DBA-team to enforce this type of "coding practice", ie (hard-coding anything like that in code)
Maybe I am confused...why would you ever be working directly with a job_id to call a job remotely? I would not bother with an extra function or round trip to resolve an ID. This should suffice and survive the scenario where someone drops and recreates a job:
I agree with you 100% here...and actually prefer calling it via the job name (in case the UID changes, you're still covered) however, to assist with the OP not getting it to work, I've also had similar situations where the job would not start using the job name...so thought I'd offer one alternative
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience