Skip to content

Tips & Tricks - Handling Error Messages and Debug Info

When a Data Migration job fails, the tool gives you the information to find the cause of the issue.

The error messages generated by the Business Logic, and will normally be the same as you'd see if you manually entered data from the client. First, examine the error and try to identify the cause for issue. Use the Execute Job Last Info Field, which gives you the log of the last execution. Row-level error messages display in the Detail tab.

Below you will find recommendations for the most frequent error-alternatives.

File Job Errors

The behaviour of the migration job on errors depends on the Rules IGNOREADERROR IGNOREADERROR and IGNOREXEERROR   IGNOREXEERROR

These are the main scenarios:

  • If the reason for the error is missing basic data, or missing default-values/job setup, then apply the fix and Restart the job.
  • If the migration is a total failure due to some issues in the input file, you can 'Clean Up' and re-run the file migration with the fixed file.

Source Job Errors

  1. Double-click on column Attribute String.
  2. Double-click on column Error Message.
  3. If you can fix the cause of the error (missing basic data, missing Source Mapping), you may
    Restart the job after the fix is applied.
  4. If the error cannot be fixed as described above, you may remove error-lines using Clean Up button.
    When selecting this option, the lines cannot be reprocessed.
  5. When you Restart the job, Data Migration will start with moving the error rows from this LU (IntfaceJobDetail)
    to the history LUs IntfaceJobHistHead and IntfaceJobHistDetail.
  6. When the dynamic SELECT-statement is built, it will be similar to the previous, except for the WHERE-clause.
    The mapped ROWID from SourceMapping has been stored in column SOURCE_ROWID on INTFACE_JOB_DETAIL_TAB
    and later on INTFACE_JOB_HIST_DETAIL_TAB.
    Now it is used to create a sub-query that replaces the original WHERE-clause.

Understand Debug info

Sometimes it is difficult to understand the reason for the error message. It might help to start the clients Debug Console and restart the job.

When executing a File Job, the debug options are not so many. Normally, you will see the attribute-string that caused the problem, and trying to enter similar data manually from the client will very often reveal the cause of the problem.

When executing a Source Job (procedure = MIGRATE_SOURCE_DATA or REPLICATION), there is a great variety of possible causes for the problem.

To view a trace of how the migration job progresses,

Open the debug console before starting the migration job from the client. After the job runs, select the entry for Server Invoke of Intface_Header_API.Start_Job procedure.
The list below explains each step in an example flow (blue text=Trace Messages, black text=Explanation):

TRACE >>>>>>>>>>>>>>>>>>>>>>> EXECUTING CONNECTED JOBS
                                                                     Job #1 for a Connected Job is executed here
TRACE >>>>>>>>>>>>>>>>>>>>>>> EXECUTING JOBS BEFORE LOOP
                                                                     Methods with Action=BeforeLoop are displayed here
TRACE >>>>>>>>>>>>>>>>>>>>>>> BUILDING SELECT STATEMENT
                                                                     Dynamic SELECT is built, based upon the setup and Mapping
TRACE >>>>>>>>>>>>>>>>>>>>>>> BUILDING DYNAMIC PL-TABLE
            TRACE >>>>>>>>>>>>>>>>>>>>>>> Exec_Seq_
            REPL_CRITERIA: XX
                                                                     Each entry in the MethodList is loaded into a table in memory. You see the sequence number from the method list (Exec_Seq_) +
                                                                     Replication Criteria (XX=NO REPLICATION, other alternatives are COMPANY or CONTRACT).
            MODIFY ATTR:
            KEY ATTR: PART_NO
            Get_Objid_Stmt BEGIN SELECT objid, objversion INTO:objid, :objversion FROM PART_CATALOG WHERE PART_NO = :PART_NO; End;
                                                                     For standard New/Modify, there will be one row in the table for each method. First, the MODIFY data is loaded into the table, and the 3 items above are important here.
                                                    MODIFY ATTR is the attribute string based on what columns are checked for OnModify in MethodListAttributes KEY_ATTR contains the columns from the MethodListAttributes that have Flag equal P or K
                                                    Finally, you see the statement generated to fetch objid/objversion for update. Note that key-values are parsed as bind-variables
            NEW
            NEW ATTR :
                                                    Second,  the INSERT data is loaded into the table. The main issue here is the attribute string.
            OTHER ATTR:
            ARGUMENT ATTR:
                                                    For procedure calls besides New/Modify, the IN-parameter for the procedure will appear in ARGUMENT_ATTR. If one of the arguments is an Attr-string, the items of the attribute string are shown in OTHERATTR.
                                                    (As specified in MethodListAttributes)
           
TRACE >>>>>>>>>>>>>>>>>>>>>>> START FETCHING DATA FROM SELECT
            DBMS_SQL.Fetch_row_
                                                    The dynamic SELECT has been executed and now we start to process the rows returned. Row-number (Fetch_row_, selected order) is displayed
            After column LOOP, SELECT attr_:
                                                    The data for each returned row is converted into an attribute string
            MASTER Key
                                                    If you use the OnMasterKey-option from the Method List, you can check the concatenated values of the Master-columns here.
                                                    More of this under Advanced Method List setup

TRACE >>>>>>>>>>>>>>>>>>>>>>> EXECUTE METHOD LIST
            Dyna count_
                                                    Now we start executing the methods in the PL-table. The Dyna_Count_ variable tells us how many methods that will be executed for each selected row.
                                                    Remember that Insert and Modify are separate rows in the table, so the value in Dyna_Count maybe twice the number of methods in MethodList.

            TRACE >>>>>>>>>>>>>>>>>>>>>>> Checking method no

Checks if this is a standard update/insert or a stored procedure.
         MethodList.column_name(i)
            MethodList.column_value(i)
            Selected column value
                                                    If you have specified ColumnName/ColumnValue in the MethodList, here is the comparison between specified value and selected value. The mismatch will skip this method

            Method MODE UPDATE
            Send key-values to cursor:
            Objid/objversion found/not found:
                                                    Modify is executed first. The Get_Objid_Statement (above) is executed with parsed key-values from the select.
                                                    Modify/New is executed depending on whether objid/objversion is found, i.e. the row already exists or not.

            Method MODE INSERT
                                                    Here the row does not exist, and method New__  will be executed
            REBUILD method_attr for view <view_name>
                                                    Here you can see the empty attribute string belonging to this method. This attribute-string is compared with the SELECT-attr, and.....
            REBUILD OUT_attr:
                                                    ..here you can see the attribute-string with values.
            Method Statement
                                                   Displays the method statement that will be executed.
            RETURN attr:
                                                   With normal termination of the method, you will see the content of the attribute-string that is returned from the method (if any)

            Method XXX failed:
            ROLLBACK to SAVEPOINT new_method_
                                                                    If the method fails, the error message will be displayed + ROLLBACK will be performed. In this case, all methods executed for this row
                                                   will be rollbacked, and the job will continue on the next row, because of Rule IGNOREXEERROR=Active.

            TRACE >>>>>>>>>>>>>>>>>>>>>>> JOB ABORTED -
                                                   If you get this trace message, Rule IGNOREXEERROR=Inactive, i.e. the complete job rollbacks when the first error occurs.

TRACE >>>>>>>>>>>>>>>>>>>>>>> EXECUTE METHODS AFTER LOOP
                                                                     Methods with Action=AfterLoop are displayed here
TRACE >>>>>>>>>>>>>>>>>>>>>>> JOB CLOSES NORMALLY WITHOUT ERRORS
                                                                     The complete job executed without errors
TRACE >>>>>>>>>>>>>>>>>>>>>>> JOB CLOSES NORMALLY. ERRORS HAVE OCCURED
                                                    Rule IGNOREXEERROR=Active and errors have occurred

 

Debug info

The item-names on the attribute string from the SELECT-statement will no longer be column name from the SourceMapping, but from now on it will be Pos prefixed with hash as shown below.

TRACE >>>>>>>>>>>>>>>>>>>>>>> START FETCHING DATA FROM SELECT
#10^015^#20^TRLY2307950035^#30^SPRING^#40^Make Onhand Analysis^         

On the start of the job, each methods individual attribute string has been pre-mapped with hash+pos in FixedValue:

REBUILD method_attr for view INVENTORY_PART :
DESCRIPTION^#30^ONHAND_ANALYSIS_FLAG^#40^

Now, we can easily match the item name from SELECT and build the final attr-string:

REBUILD OUT_attr: DESCRIPTION^SPRING^ONHAND_ANALYSIS_FLAG^Make Onhand Analysis^

The benefit of this will be:

  1. The SELECT-attr will become much shorter and also easier to fetch data from.
  2. Each methods attr will only contain items that are mapped in Maintenance Job/SourceMapping.
  3. The direct reference between item-name on SELECT-attr and each individual attr makes processing faster