Resolving SIMATIC BATCH 'Batch Could Not Be Archived' Error

1. Problem Overview

The SIMATIC BATCH server reports the message "Batch could not be archived" in the Batch Control Center for individual batch records even though the archive files (XML master data + PDF report) appear on disk and the affected batches display the padlock / locked icon in the batch list. The condition is intermittent: only a subset of completed batches fails to clear the pending archive status, while the remainder archive normally on the configured schedule.

This behavior is reproduced in PCS 7 / SIMATIC BATCH installations using the auto-archive function (default 24 h after batch close in many plants). The failure does not indicate that the XML/PDF archive pair is missing — the pair is created successfully on the first archive attempt. The red status in the Batch Control Center and the locked icon persist because the BATCH server attempts a second archive transaction, finds the archive target already populated, and aborts with the generic error.

2. Symptoms Checklist

Engineers should confirm the following field indicators before applying the resolution steps in Section 5:

The two-stage failure pattern (first archive succeeds, a follow-up attempt ~30 minutes later fails) is the most reliable fingerprint of this defect and is the trigger for the Siemens-recommended fix.

3. Root Cause Analysis

Siemens documents the underlying defect in the support article SIMATIC BATCH: Message indicating archiving problems when updating a batch process cell. The proximate cause is duplicate identifiers in the BATCH database for the data types used by the affected batches.

The BATCH database (Microsoft SQL Server, typically named BATCH or project-specific) stores the master data catalog that maps each formula / recipe / data type to a numeric identifier. Over the life of an installation — particularly across software updates, process cell re-engineering, and bulk imports of master data from older releases — multiple rows can accumulate with the same data type ID. When the archive routine processes a batch whose data type participates in this duplicate set, the SQL join produces a non-unique result, the archive transaction is rolled back, and the server flags the batch as archived with error.

The defect manifests in the user interface as a residual "could not be archived" status because:

1. The first archive pass reads the BATCH database without the duplicate-ID filter, writes the XML and PDF correctly, and the on-disk artifacts are present.
2. The follow-up pass (default interval ~30 min, controlled by the BATCH server's archive retry loop) attempts to re-archive; the duplicate-ID join produces a multi-row result and the second write fails, leaving the batch marked as error in the database even though the archive itself succeeded on disk.
3. Restarting the BATCH service does not clear the status flag for batches whose database row already records the failed state, so the error persists across reboots until the underlying data is corrected.

3.1 Trigger Conditions

Three operator actions are known to expose latent duplicate IDs:

• Bulk import of process cell data from a backup or a sibling project without purging the staging schema.
• Applying a SIMATIC BATCH update (for example, upgrading from V8.2 to V9.0) without running the supplied database migration script.
• Manual edits to BATCH master data in the engineering tool (BATCH Configuration) that re-use an existing data type ID after a process cell is re-versioned.

4. Affected Versions and Update Matrix

The following table summarizes the released patch level and the database optimization requirement. The patch addresses the symptom; the database optimization eliminates the root cause.

5. Resolution Procedure

Resolve the fault in the order shown. Skipping the database optimization and applying only the patch leaves the historical duplicate rows in place, and the error will resurface after the next process cell update.

5.1 Prerequisites

• Windows administrator account on the BATCH server with local admin rights.
• SQL Server sysadmin role membership for the BATCH database.
• Confirmed full backup of the BATCH database and the archive directory.
• Scheduled maintenance window — the BATCH server will be stopped for the duration.
• SIMATIC BATCH installation media for the current version (for the update install).

5.2 Step 1 — Snapshot the BATCH Database and Archive Directory

1. Stop the SIMATIC BATCH service: net stop "SIMATIC BATCH Server" from an elevated command prompt.
2. Stop any active Batch Control Center clients to release database locks.
3. In SQL Server Management Studio, take a full database backup of the BATCH database to a network share. Verify the backup set with RESTORE VERIFYONLY.
4. Copy the entire archive directory (default: C:\Siemens\Automation\Batch\Archive or the project-specific path) to a separate location. Confirm the XML/PDF pairs for the affected batches are included.

5.3 Step 2 — Apply SIMATIC BATCH Update

1. Mount the SIMATIC BATCH installation media for the current major version.
2. Run Setup.exe and select Update Installation.
3. Confirm the installed build number matches the target patch (for example, 9.0.1.3).
4. Allow the installer to migrate the BATCH database if prompted. Do not interrupt the migration — interruption leaves the database in a partial state.
5. Reboot the BATCH server.

5.4 Step 3 — Run the BATCH Database Optimization

Siemens ships a SQL script with the support article 109962043. The script identifies and de-duplicates the offending data type rows. Execute the following procedure:

1. Stop the SIMATIC BATCH service.
2. Open SQL Server Management Studio and connect to the BATCH database engine.
3. Open the optimization script supplied with the support article. The script is a single batch with three sections: identification, preservation of the canonical row, and removal of duplicates.
4. Execute the identification section first. Review the result set. The query targets the data type table (commonly BB_DataType or project-specific equivalent) grouped by ID. Duplicate IDs appear as groups with a row count greater than 1.
5. Execute the de-duplication section inside a BEGIN TRAN block. The canonical row is selected as the row with the lowest ID value (or the most recent LastChange timestamp, depending on the project-specific script). The script reassigns foreign-key references in BB_Batch and BB_Formula to the canonical row, then deletes the duplicates.
6. Run the verification query (also part of the script) to confirm no duplicate IDs remain. Expected result: zero rows.
7. Commit the transaction: COMMIT TRAN.

The canonical SQL pattern (illustrative — use the script shipped with the support article, not this excerpt):

-- Identification: locate duplicate data type IDs
SELECT ID, COUNT(*) AS DupCount
FROM dbo.BB_DataType
GROUP BY ID
HAVING COUNT(*) > 1;

-- De-duplication (execute inside a transaction)
BEGIN TRAN;

-- Preserve the canonical row, reassign references, remove duplicates
UPDATE b
   SET b.DataTypeID = canon.ID
  FROM dbo.BB_Batch AS b
  JOIN dbo.BB_DataType AS dup  ON dup.ID = b.DataTypeID
  JOIN dbo.BB_DataType AS canon ON canon.DataTypeName = dup.DataTypeName
                               AND canon.ID = (SELECT MIN(ID)
                                                 FROM dbo.BB_DataType
                                                WHERE DataTypeName = dup.DataTypeName);

DELETE dup
  FROM dbo.BB_DataType AS dup
  JOIN dbo.BB_DataType AS canon ON canon.DataTypeName = dup.DataTypeName
                               AND canon.ID < dup.ID;

-- Verification: should return zero rows
SELECT ID, COUNT(*) AS DupCount
  FROM dbo.BB_DataType
 GROUP BY ID
HAVING COUNT(*) > 1;

COMMIT TRAN;

5.5 Step 4 — Clear the Stuck Archive Status Flag

After the database optimization, batches that were marked "could not be archived" still carry the error flag in the database. The status is cleared by the BATCH server on the next archive cycle once the underlying data is clean. To force the clearance for the previously affected batches:

1. Start the SIMATIC BATCH service.
2. Open the Batch Control Center and locate the affected batch rows.
3. Right-click each affected batch and select Archive from the context menu. The server re-evaluates the batch with the cleaned master data and transitions the status from error to archived.
4. Confirm the padlock icon is removed and the row status reads "Archived".

For sites with many affected batches, the equivalent action can be triggered by running the auto-archive job (default 24 h schedule) without manual interaction. Verify the new archive files overwrite or supersede the prior XML/PDF pair consistently with the project's archive retention policy.

6. Verification

Execute the following checks after the resolution. A clean result on each confirms the fault is closed.

7. Preventive Measures

• Patch cadence: Track Siemens SIMATIC BATCH updates quarterly. The V9.0 SP1 Upd3 release is the current correction level at the time of writing; later hotfixes and V9.1 service packs incorporate the fix.
• Process cell update discipline: Use the engineering tool's built-in "Update Process Cell" workflow exclusively. Avoid direct SQL edits to the BATCH database outside of scripts issued by Siemens support.
• Pre-update database check: Add the duplicate-ID identification query to the change management procedure. Run it before every BATCH update and reject the change if duplicates are detected.
• Restart hygiene: The defect surfaces more readily when the BATCH server is restarted while batches are mid-archive. Schedule server restarts during production gaps, not while the archive job is running.
• Archive directory review: Periodically confirm the archive directory contains the expected XML/PDF pair count. A discrepancy between database row count and archive file count is an early warning of an archive fault.

8. Troubleshooting Matrix

9. Edge Cases and Field Notes

Multi-server BATCH topologies: In redundant or load-balanced BATCH server configurations, the archive retry loop is coordinated by the active server. After applying the optimization, confirm the standby server is also restarted so it picks up the cleaned database state — otherwise the next failover can reintroduce the error.

Audit trail integrity: The optimization script preserves the canonical row and only removes the duplicates. The audit trail (BB_Log) and the batch results (BB_BatchResult) are not modified. Plants under FDA 21 CFR Part 11 or GAMP 5 validation should record the script execution in the change control register and retain the pre- and post-execution SQL backups for the validation retention period.

Custom master data: Sites that have extended the BATCH data model with project-specific columns must verify the optimization script handles the custom schema. The script targets the standard tables; custom tables that reference the duplicated IDs are not auto-cascaded. A pre-execution review with the project's automation engineer is recommended.

Archive retention policy: The auto-archive function moves batch data from the operational tables to the archive tables in the BATCH database. The XML/PDF files on disk are the long-term artifacts. Sites that have configured archive compression or offload-to-archive should verify the offload path is reachable from the BATCH server before the maintenance window opens.

10. Related Siemens Support Resources

• SIMATIC BATCH: Message indicating archiving problems when updating a batch process cell — primary support entry with the optimization script.
• SIMATIC BATCH V9.0 SP1 update release notes — patch level Upd3 documentation.
• SIMATIC PCS 7 / SIMATIC BATCH Configuration manual — process cell update workflow.
• Siemens Industry Online Support portal — searchable index of BATCH-related entries by error message string.