I guess I am not the only one that has installed NAV 2016 running the Job Queue. If the Job Queue is running a job that causes error you are likely to start the debugger on the service tier running the Job Queue and start with a Debug Next.
You can expect a break point with an error similar to this one.
Well, not what you where hoping for. Not the job you where planning to debug, right. Well, you try again and get the same error, never getting to the error you wanted to debug in the first place. And why is that?
Microsoft decided to utilize the TryFunction in the Job Queue
So, each time JobQueueEntry.FINDFIRST fails the debugger breaks. So I asked Microsoft, why change this from being an normal function containing EXIT(JobQueueEntry.FINDFIRST). The response was:
“We wrapped the FINDFIRST in a TRY-function because we regularly got (dead-)lock errors when we had multiple queues running at the same time, and this fix has virtually eliminated that problem. And since we cannot have return values from try-functions, we would have to pass on a boolean VAR parameter to indicate if it was found or not.”
Ok, so there is a reason, and a good one.
So I started a little ping pong with Microsoft and we agreed that this should be fixed. A new local function was added to Codeunit 448 and the TryFunction was modified. The previous call to a TryFunction was modified to call the new local function instead.
So, both problems fixed; (dead-)lock not causing the Job Queue to stop and we are not getting troublesome break points in the debugger.
Attached are Delta, FOB and TXT versions for this fix.