When a Data Migration job fails, you will normally see the error-rows from menu
path Execute Job/folder Details.
The error-message is generated by Business Logic, and will normally be the same
as you'd see if you manually entered data from the client.
Below you will find recommendations for the most frequent error-alternatives.
Sometimes it is difficult to understand the reason for the error-message. It might
help to start the clients Debug Console with the Trace_SYS option and restart the
job.
Below you will find explanation of the trace information
as well.
The error info may look like this. You will see the File String, formatted
Attribute String and Error Message for Business Logic. How the migration job
behaves on errors
depends on the Rules
IGNOREADERROR
and IGNOREXEERROR
These are the main scenarios :
2. Search in the context of 'Detail' tab for lines which are not OK.
3. Temporarily hide all the columns except for 'File String' using the 'Column Chooser'.
4. Since only the non executed lines are listed now, output 'All rows' from the channel.
5. RMB on the column header and 'Reset Current View'
6. Fix errors in the file
7. Clean Up the details in the execute job window and 'Start Online' the job again
If errors occur, you may see error rows from menu path Execute Job/folder Details.
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 client. After the job runs, select the entry for Server Invoke of Intface_Header_API.Start_Job procedure. In the bottom tab pane, select the pl/sql trace and filter for 'Trace' and 'Application'
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. 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 is shown in OTHER ATTR.
(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 may be 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. 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 next row,
because Rule IGNOREXEERROR=Active.
TRACE >>>>>>>>>>>>>>>>>>>>>>> JOB ABORTED -
If you get this trace message, Rule IGNOREXEERROR=Inactive,
i.e. the complete job rollbacks when 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
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 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 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 :