What Is Row-Error Tolerance in a Data Import?

Row-error tolerance is the import setting that decides whether one bad row fails on its own while the rest of the run continues, or whether the whole run stops at the first problem. It sounds like a small preference and it is the difference between a five-minute weekly routine and an afternoon of frustration. In EDGEBIC by User Solutions the setting lives on the import mask itself, alongside the mask's other options, and it defaults to continuing, so a single malformed row never costs you the other hundred and ninety-nine.

How it works

Every row in an import file resolves to exactly one outcome. Created means a new record was written. Updated means an existing record was changed. Reused means an existing record was found and deliberately left alone. Failed means something about the row was wrong and it was not applied. Those four outcomes and their vocabulary are covered in what is an import row status.

Row-error tolerance governs only what happens after a Failed outcome:

The reason for a failure is never lost in either mode. The result dialog summarizes the run with a count line reading created, updated, reused and failed, plus a grid with one entry per file row showing the row number, its status, the key it matched on, a message, and the resulting record id. The per-run log file records the same detail plus the bookkeeping rows the dialog hides. That combination is what turns "the import did not work" into "row 47 has a blank product id."

There is a second, different failure that people frequently confuse with row-error tolerance, and separating them saves real time. If a field the mask marks as required was never mapped, the run aborts immediately and no rows are processed at all, regardless of the tolerance setting. That is a mask problem, fixed by editing the mask and mapping the field. A Failed row, by contrast, is a data problem, fixed in the spreadsheet.

Recovery in both modes is the same move: fix the source and re-run. Imports are designed to be safe to re-run because rows are matched by a business key rather than blindly appended, so rows that already landed come back as Reused or Updated rather than duplicating. That matching behavior is described in what is an upsert in data import, and it is the reason a partial run is an inconvenience rather than a mess.

A concrete example

A planner runs a saved weekly product mask against this week's price file. The run finishes and the result dialog reads created 3, updated 0, reused 1, failed 1, in two seconds. Four of the five rows behaved exactly as expected. The fifth is highlighted with a message naming the problem, and the log gives its row number.

With tolerance on, the three new products exist, the one matched product was left alone as the mask's update option is off, and the single bad row is a note to send back to whoever produces the file. Total planner effort: read one message.

Now imagine the same file with tolerance off. The run stops at the bad row. Anything before it landed, anything after it did not, and the planner is left reconciling. The fix is to correct the row and re-run the whole file: the earlier rows return as Reused or Updated, the corrected row lands, and the totals come out right. It works, it just costs an extra cycle for no benefit, which is exactly why the default is to continue.

The one case where stopping earns its keep is a first run. A brand-new mask against a file nobody has imported before can be wrong in a way that repeats on every row: the wrong source column dragged onto the identifier, or a positional mapping shifted by one. Stopping at the first failure surfaces that in seconds instead of producing two hundred identical failures to scroll through.

How EDGEBIC uses it

The setting is one of the checkboxes in a mask's options dialog, and it applies to every entity type, unlike the options that are specific to a single type. Because it lives on the mask rather than being chosen per run, a recurring routine behaves the same way every week without anyone remembering to set it.

Three habits go with it:

• Dry-run a new mask on ten rows. Ten rows prove the mapping. Then run the full file with tolerance on.
• Read the log after any run with failures. The dialog gives you counts; the log gives you row numbers and reasons. Log files are written one per run, named after the mask and the timestamp, and are kept until you delete them. See what is an import run log for what is in them.
• Treat repeated failures as a source-file conversation. If the same three rows fail every week, the fix belongs upstream in whatever produces the file, not in a manual patch after each run.

One thing to keep in perspective: no import setting ever changes the plan. Imports write data, and the schedule is recalculated only when you run the scheduler. A file that lands forty new orders leaves forty jobs waiting to be planned and not a single bar on a timeline until the next scheduling run. That separation means an import you have to re-run is never a scheduling emergency.

The takeaway

Row-error tolerance is a one-checkbox decision with a clear default: let bad rows fail alone, report them precisely, and fix them at the source. Turn it off only while you are proving a new mapping, then turn it back on. Combined with key-based matching, that policy makes a weekly data load boring, which is the highest praise a data routine can earn. To see masks, options and result dialogs in a working system, explore EDGEBIC, and if you are arriving from the older Resource Manager lineage, the move from RMDB to EDGEBIC maps the equivalents. For neighboring import terms, read what is an import entity type and what is a conversion factor in data import.