MDS staging errors: where they hide, and what every error code actually means

When an MDS staging batch finishes, every processed row in the staging table gets a value in its ErrorCode column, and the readable explanation lives in two views in the Master Data Services database that almost nobody finds:

• stg.viw_name_MemberErrorDetails — leaf and consolidated member updates
• stg.viw_name_RelationshipErrorDetails — hierarchy relationship updates

Replace name with your staging table name. The explanation is in the ErrorDescription column.

SELECT * FROM stg.viw_Product_MemberErrorDetails;
SELECT * FROM stg.viw_Product_RelationshipErrorDetails;

Two prerequisites catch people out: you need SELECT permission on the view, and you must be a model administrator. If the view returns nothing and you were expecting rows, check both before you start debugging the data.

Why this is harder than it should be

A staging batch does not fail. It completes, and some of the rows quietly did not become members. The batch status is the same either way, which is why teams discover the problem days later when somebody notices a product missing from a report. (If your batch never reached “completed” in the first place — stuck on Queued to Run, or wedged on Running — that is a different fault entirely, and we walk through those in when a staging batch is not processing.)

There is no notification, no summary, and nothing in the web UI that says “forty-one rows were rejected for three distinct reasons”. If you run staging on a schedule, the practical advice is to query the error views as a step in the job itself and alert on a non-zero count. Almost nobody does this, and it is the single cheapest improvement you can make to an MDS installation.

Every error code, grouped by what went wrong

Microsoft documents these as one flat list sorted roughly by number, which is not how you meet them. Grouped by cause, the same codes make a lot more sense.

Domain-based attributes — the ones you will actually hit

Duplicates and members that do or do not exist

Code generation and reserved words

Hierarchies and relationships

Three mistakes behind most of these

Staging the name instead of the code. Someone exports a spreadsheet where the category column reads Hand Tools, because that is what a human wants to see, and stages it directly. Domain-based attributes resolve by code. Every one of those rows comes back 210003. If you are loading from anything a person touched, translate names to codes before staging, not after.

Using the wrong ImportType for what you are doing. A surprising share of codes are really the same complaint: this operation does not match the state of the data. 300004 is create-when-it-exists. 300002 and 210006 are modify-when-it-does-not. 210052 is deactivate-when-something-still-points-at-it. Before debugging the row, check the ImportType is the one you meant.

Letting duplicates into the batch itself. 210001 and 210015 both mean the staging table disagreed with itself. Worth noting how unforgiving 210001 is: when a code appears twice, neither row is applied. Not the first, not the last. Both are dropped, which is why a batch can quietly leave a member completely absent rather than merely stale.

Make the batch tell you

If you take one thing from this: add a check after the staging step so a partial load cannot pass silently.

-- Fail the job if anything was rejected
DECLARE @Rejected INT;

SELECT  @Rejected = COUNT(*)
FROM    stg.viw_Product_MemberErrorDetails;

IF @Rejected > 0
    THROW 50001, 'MDS staging rejected rows - check the error views.', 1;

Crude, and better than finding out at month-end. Group by ErrorCode in the alert and the cause is usually obvious from the distribution alone — four hundred rows of 210003 is a name-versus-code problem, not four hundred separate mistakes.

One thing worth saying

The Microsoft documentation pages for these error codes now carry a banner explaining that MDS is removed in SQL Server 2025. The reference is still accurate and still useful — SQL Server 2022 is supported into 2033, so plenty of people will be reading staging errors for years yet. But nobody is going to improve this tooling now, and the error views are exactly as discoverable as they were in 2010.

If you are debugging staging often enough to have found this page, that is worth weighing. Not as a reason to panic — nothing breaks in 2028 whatever you have read elsewhere — but the effort you spend building alerting around a staging process is effort spent on a product with no roadmap. Our end-of-life checklist covers the timing honestly, and getting your data out covers the mechanics.

What this looks like when it is not silent

Primentra stages data too, and the difference is mostly in what happens to a bad row. Validation runs per field with the reason attached to the row, rejected records surface in the UI rather than in a view you have to know the name of, and domain values resolve by lookup so the name-versus-code trap does not arise in the first place. We wrote up the mechanics in import actions and merge modes and the automation in inside the staging scheduler.

Frequently asked questions