Your MDS staging batch is not processing. Work down this list.

“The staging batch is not processing” describes at least four different faults in MDS, and they share almost nothing. Rows that never appear as a batch at all is a filtering problem. A batch stuck on Queued to Run is a Service Broker problem. A batch stuck on Running is a BatchTag problem. A batch that completed while quietly dropping rows is a data problem.

The two stuck states get conflated constantly, and it wastes hours, because the fix for one does nothing for the other. Start by finding out which state you are actually in.

First, get the real status

The web UI shows batch status under Integration Management once you pick a model, but the table underneath is faster and does not make you guess which model to look in.

SELECT * FROM [mdm].[tblStgBatch] ORDER BY ID DESC;

1. The rows never show up as a batch

You loaded five thousand rows into the staging table, and the Unbatched Staging Records pane shows nothing, or a number that does not match. Nothing failed, because nothing ran — MDS filtered your rows out before they became a batch. Four fields decide this, and all four must be right:

• UserName — must be Domain\user_name, computer\user_name, or NULL.
• Batch_ID — must be NULL. A leftover value means the row already belongs to a batch.
• Status_ID — must be 0.
• ModelName — must match the model name exactly, including case.

That last one deserves its own warning. A ModelName of product against a model named Product produces no error, no warning, and no rows. If an ETL job started returning zero after someone rebuilt it, check the case before anything else.

-- Why are my rows invisible?
SELECT  ModelName, UserName, Batch_ID, Status_ID, COUNT(*) AS Rows
FROM    stg.Product_Leaf
GROUP BY ModelName, UserName, Batch_ID, Status_ID;

Two adjacent cases belong here. If the model is missing from the Model list entirely, you are not a model administrator for it — importing requires that role. If the model is there but the version is not, the version is Committed. Committed versions are closed to import; you need one that is Open or Locked.

2. Stuck on “Queued to Run” — Service Broker

The batch was created and accepted, and then nothing happened. It sits on Queued to Run indefinitely. This is not a data problem and no amount of inspecting your rows will help.

MDS dispatches staging batches asynchronously through a Service Broker queue. If Service Broker is disabled on the MDS database, batches queue and never start. This bites most often after a database restore, because restoring can leave the broker disabled even though it was enabled on the source.

USE master;
SELECT is_broker_enabled, name FROM sys.databases WHERE name LIKE 'MDS%';

-- If is_broker_enabled is 0, enable it (your database name may differ)
ALTER DATABASE MDS SET ENABLE_BROKER;
GO

3. Stuck on “Running” forever — BatchTag collision

Different symptom, different cause. The batch started and never finished, and somewhere you saw:

MDSERR310029  The status of the specified batch is not valid.

Here is the part that catches everyone: MDS checks BatchTag status regardless of model. BatchTag is effectively global across the instance, not scoped to the entity or the model you are loading. So two unrelated loads — a Product entity in one model and a Customer entity in another — that both use a BatchTag of daily will collide, and one of them wedges.

This is why the fault often appears the day someone adds a second scheduled load, having copied the first job and changed only the entity name. Recovery is three steps:

-- 1. Stop the wedged batch process
EXEC [mdm].[udpStagingBatchQueueActivate];

-- 2. Give the records a BatchTag nothing else is using,
--    and reset them so they are eligible again
UPDATE  stg.Product_Leaf
SET     BatchTag        = 'product_leaf_2026_07_25',
        importstatus_ID = 0
WHERE   BatchTag = 'daily';

Then rerun the staging procedure. The importstatus_ID = 0 part is not optional — leave it and the rows stay ineligible no matter what you call the batch.

The permanent fix: stop using static BatchTag values. Make them unique per run — entity name plus a timestamp is enough. A tag like daily or load1 in a shared instance is a collision waiting for a second job to exist.

4. It runs, but takes far too long

A batch that used to take two minutes and now takes forty is usually not stuck — the statistics on the MDS database are stale. The staging procedures do a great deal of joining against internal tables that grow steadily, and the plans degrade with them.

USE MDS;
EXEC sp_updatestats;

5. It completed, and rows are still missing

This is the one that is not a processing failure at all. The batch ran to completion and individual rows were rejected on their own merits, each stamped with a value in the ErrorCode column. Nothing in the UI announces this. We covered where the explanations hide and what each code means in MDS staging errors.

Three habits that prevent most of this

Unique BatchTag per run. Removes case three permanently, costs one line of SQL.

Check the broker after any restore. Add is_broker_enabled to whatever you already check after refreshing a non-production environment from a backup.

Assert the row count. Compare what you loaded into staging against what became members, and fail the job on a mismatch. Every failure mode on this page is silent, and a count comparison catches all of them at once without needing to know which one you hit.

Worth saying out loud

The underlying issue here is that a globally scoped BatchTag, an asynchronous queue with no visible failure, and a case-sensitive model name filter that silently returns nothing are all design decisions from around 2010 that were never revisited. The knowledge-base article describing the BatchTag collision is old enough to vote.

None of it is going to improve now. MDS is removed in SQL Server 2025, and SQL Server 2022 is patched into 2033, so this page will stay useful for years — but the alerting you build around this staging process is investment in a product with no roadmap. Our end-of-life checklist covers the timing without the usual exaggeration.

What this looks like elsewhere

Primentra stages data too, and the difference is that a batch reports what it did. Row counts in and out are shown together, rejected rows carry their reason in the interface, and batch state is visible without querying an internal table for it. The scheduler has explicit guards against the concurrency problems that leave a batch wedged — we wrote that up in inside the staging scheduler, and the load options in import actions and merge modes.

Frequently asked questions