I’ve got my source migration job working, but I’m trying to log errors that just show up as unprocessed records. In this case it’s a bad Operation No/ID and you can see in the debugger it can’t find the Objid/Objversion for the routing operation I’m trying to update. Is there a way to flag these rows so the end users can go back and resolve the issue with the source data?
Thanks, Lane
Page 1 / 1
Normally the migration job logs for errors for each row and stops if there are errors unless you have setup a rule to ignore errors. Do you have such rukes setup in your migration job?
Fie example, IGNOREXEERROR will continue procedure on error. The rules are setup in the rules tab. If this rule is activation, disable it so that user will see the errors during execution.
I should have put in the original message IGNOREXEERROR is set to inactive and nothing is put into the detail tab of the Execute Job screen. The only clue that there was a problem is that it shows fewer rows where updated than selected.
I ended up adding a couple more methods to the migration job. The first method calls exist_operation and if it returns a 1 then the second method updates a row status column.
You can normally check out the errors in the execute job menu after execution
Unfortunately in this case it doesn’t. I saw the errors you are referring to when I was trying to get the Intface_Table_Migrations_API.Process_Table call working.
Any difference whether you run migration “online” or select “background”?