Here’s another behaviour change that I’ve found with DS4.2 sp8.1.
From my previous experience, it is the case that it is only possible to run a failed job with the ‘Recover from last failed execution’ option selected if you haven’t made a code change. If you have made a code change to fix the job, you can’t run it in recovery mode.
So I was surprised to find that, in DS4.2 sp8.1, after I’d made a code change and saved the job, it was possible to run the job in recovery mode and it started at the point just prior to where it had previously failed.
I’m wondering if this is a deliberate change from SAP? I can’t find any mention of it in the release documentation and I’m going to raise it with the helpdesk.
In prior versions of DS (before 4.x) each time you saved an object a new version was created (new row in the repository, new version number). So in that case I could see where the execution of the job might be tracking the version of the object. But now in 4.x, each time an object is saved it does an update in place. So the version number in a local repository is always 1.
I don’t use recovery mode so I can’t confirm your experience.
My take away is that this is a net positive change. In the past they may not have known how to handle the updated code but now they do?
I do know that when a local repository was creating a new version of an object in AL_LANG whenever it was saved that invalidated the statistics for that object because the stats were tied to the version number. Now that local repositories aren’t creating new versions maybe they realized they can do a recovery restart OK.
(BOB member since 2004-06-09)
(BOB member since 2007-09-12)
(BOB member since 2004-06-09)