WinCC Tag Deletion Failed: Fix Structure Element Error

Problem Overview

When configuring a Siemens WinCC project, an engineer or commissioning technician creates a tag using an invalid character — most commonly a dot (.) where an underscore (_) was intended. The tag is accepted by the tag dialog and saved to the WinCC project database. A subsequent attempt to delete that tag returns the dialog error:

"The selected object is a structure element or contains structure elements. First delete the associated structure tag and then repeat the deletion procedure."

WinCC refuses the deletion because the tag has been internally registered as a child element of an implicit (orphaned) structure tag, or because the name-validation rules of a structure element have been violated by the user input. The tag cannot be deleted through the standard Tag Management editor, the Tag Logging editor, the Alarm Logging editor, or the WinCC Explorer. This article documents two field-proven recovery paths: (1) direct manipulation of the Microsoft SQL Server configuration database, and (2) the official WinCC Configuration Tool add-on for Microsoft Excel. A prevention section, a verification procedure, a troubleshooting matrix, and a FAQ close the reference.

Why This Happens: WinCC Tag Naming and Structure Mechanics

WinCC project databases (files with the extension .mcp) and runtime databases (Microsoft SQL Server databases prefixed with the project name and ending in R) enforce a strict naming convention for tags. Tags can exist in three forms:

The dot character (.) is reserved internally as the structure-element separator when the runtime engine resolves a hierarchical tag path such as MyStruct.Motor.Speed. When a tag named Pump.01.Run is entered into the Tag Management editor, WinCC does not always reject the name at the input prompt (depending on the WinCC version and locale settings). Instead, the editor interprets it as element Run inside element 01 inside structure Pump. If those parent structures were never formally defined as UDTs in the project library, WinCC creates implicit (orphaned) structure rows in the dbo.MCPTVARIABLEDESC and dbo.MCPSTRUCTURE tables to satisfy the reference. Once those implicit structure rows exist, the Tag Management dialog refuses to delete the leaf tag until the parent structure tag is deleted first — and the parent structure cannot be deleted through the UI because it has no graphical representation in any editor.

How WinCC Stores Tags: Database Schema Reference

WinCC V7.x and WinCC V8 (TIA Portal) both use Microsoft SQL Server as the project backend. The configuration database and the runtime database are separate, even though they share a project name prefix. The relevant tables for tag definition are:

Tag deletion must be performed exclusively in the configuration database. Editing the runtime database can corrupt the archive and is never required to remove a tag definition.

Prerequisites for Recovery

Before attempting either recovery method below, perform the following preparation steps in order:

1. Close the WinCC Explorer, the Tag Management editor, the Graphics Designer, and any client connected to the runtime database.
2. Stop the WinCC Runtime services on the WinCC server to release exclusive locks on the SQL database. From an administrative command prompt:

   net stop "CCArchiveConnMgr"
   net stop "CCProjectMgr"
   net stop "CCRuntime"

   Alternatively, use the Windows Services console (services.msc) and stop the SIMATIC WinCC service group.
3. Take a full backup of the WinCC project folder and the SQL databases. Back up the SQL configuration and runtime databases via SSMS or a .bak file using the maintenance plan.
4. Identify the SQL Server instance. By default, WinCC V7 uses the SQL Server instance named WINCC; WinCC V8 (TIA Portal) uses WINCCPLUS. Verify by running SELECT @@SERVERNAME in SSMS.
5. Confirm you have SQL db_owner rights on the WinCC configuration database, or use the SA account installed during WinCC setup.
6. Document the corrupted tag name, the time of discovery, and the operator who created it. This becomes part of the change record.

Method 1 — Direct SQL Deletion (High-Risk, Field-Proven)

This method is the original workaround circulated on Siemens support channels and reproduced by multiple field engineers. It directly modifies the configuration database table. Use only after a verified backup has been confirmed restorable.

Procedure

1. Open Microsoft SQL Server Management Studio (SSMS) from Start → Programs → Microsoft SQL Server → SQL Server Management Studio.
2. Click Connect. The WinCC setup installs SQL Server with mixed-mode authentication; the SA account is created during installation with the password defined in the WinCC installer wizard.
3. In Object Explorer, expand Databases and locate the configuration database. The configuration database is named <ProjectName> (no suffix). The runtime database is <ProjectName>_R. Do not edit the runtime database for tag-definition issues.
4. Expand the configuration database, then expand Tables. Locate dbo.MCPTVARIABLEDESC.
5. Right-click dbo.MCPTVARIABLEDESC and select Edit Top 200 Rows (or Open Table in older SSMS versions).
6. Locate the orphaned tag. The VARIABLENAME column contains the dotted name. Use the SSMS filter on the VARIABLENAME column. To find all suspect rows at once:

   VARIABLENAME LIKE '%.%'

7. Review every row. Confirm that the row is not referenced by any alarm, archive, or script. Cross-check the related tables by joining on VARIABLEID:

8. Right-click the row selector of the orphaned tag and select Delete. Confirm the deletion in the dialog.
9. If the delete fails with a foreign-key constraint violation, identify the referencing row using the queries above and delete dependent rows first, then retry.
10. Close SSMS. Restart the WinCC Runtime services from the administrative command prompt:

    net start "CCArchiveConnMgr"
    net start "CCProjectMgr"
    net start "CCRuntime"

11. Open the WinCC project in the WinCC Explorer. The orphaned tag should no longer appear in Tag Management. Verify the project compiles cleanly via Project → Compile → All.

SQL Reference: Safe Identification Query

-- Identify orphaned structure references for a suspect tag
SELECT
    vd.VARIABLEID,
    vd.VARIABLENAME,
    vd.STRUCTURENAME,
    vd.STRUCTUREID,
    vd.PARENTID
FROM dbo.MCPTVARIABLEDESC AS vd
WHERE vd.VARIABLENAME LIKE '%Pump.01%'
   OR vd.STRUCTURENAME LIKE '%Pump.01%'
ORDER BY vd.STRUCTUREID, vd.PARENTID, vd.VARIABLEID;

If multiple rows are returned, delete from the deepest child first — the row with no other rows referencing its STRUCTUREID as a PARENTID — to avoid foreign-key violations during cascading deletes.

Transaction-Safe Delete Wrapper

BEGIN TRANSACTION;

-- Preview the row to be deleted
SELECT * FROM dbo.MCPTVARIABLEDESC WHERE VARIABLENAME = 'Pump.01.Run';

-- Confirm the previewed VARIABLEID matches expectations, then:
DELETE FROM dbo.MCPTVARIABLEDESC WHERE VARIABLENAME = 'Pump.01.Run';

-- Verify the row count
SELECT @@ROWCOUNT AS RowsAffected;

-- If the count is correct, commit. Otherwise roll back.
-- COMMIT TRANSACTION;
-- ROLLBACK TRANSACTION;

Method 2 — WinCC Configuration Tool in Excel (Recommended)

The WinCC Configuration Tool is an Excel COM add-on distributed on the WinCC installation media under Add-ons → Configuration Tool. It exposes the project database as an Excel workbook and supports bulk import, export, rename, and deletion of tags, alarms, and texts while respecting WinCC's internal referential checks. This is the officially supported path and the recommended approach on production systems.

Installation

1. Insert the WinCC installation DVD or mount the ISO image.
2. Run Setup.exe and select Custom Installation.
3. Navigate to WinCC → Options → Configuration Tool and enable it.
4. Complete the installation. The add-in registers itself in Microsoft Excel. Excel bitness must match the WinCC installation: WinCC V7.x requires 32-bit Office; WinCC V8 (TIA Portal) and WinCC Unified require 64-bit Office.
5. Restart Excel to load the COM add-in.

Deletion Procedure

1. Open Microsoft Excel (matching the bitness of your WinCC installation).
2. Confirm the WinCC Configuration ribbon is visible. If it is missing, enable it via File → Options → Add-Ins → Manage: COM Add-Ins → Go and tick WinCC Configuration Tool.
3. Click Open Project in the ribbon and select the project's .mcp file. Excel loads the tag table.
4. Sort or filter the Tag Name column to locate the orphaned tag (e.g., Pump.01.Run).
5. Select the entire row corresponding to the orphaned tag. Right-click → Delete Row, or use the Configuration Tool ribbon's Delete Selected command.
6. Click Save in the Configuration Tool ribbon. The tool writes the modified table back to the SQL configuration database with proper transaction handling and referential checks.
7. Close Excel. Open WinCC Explorer and recompile the project via Project → Compile → All.

Alternative Workaround: Rename Then Delete

If direct deletion remains blocked even through the Configuration Tool, a two-step workaround often succeeds and requires no database editing:

1. Rename the orphaned tag to a valid scalar name (e.g., Orphaned_Tag_Old) using Tag Management or the Configuration Tool. This breaks the dotted-name structure reference inside MCPTVARIABLEDESC by rewriting VARIABLENAME to remove the structure interpretation.
2. Delete the renamed tag normally through Tag Management — no error appears because the tag is now a scalar with no implicit parent structure.

This works because the rename operation rewrites the VARIABLENAME column to a form that no longer triggers structure-element interpretation. The original problem record is effectively overwritten.

WinCC Version-Specific Notes

For WinCC Unified systems, tag management is performed inside TIA Portal rather than the WinCC Configuration Tool add-on. If an invalid dotted tag is created in WinCC Unified, the recovery path is to delete the tag via TIA Portal → PLC tag table or HMI tag table, recompile, and download to the runtime.

Multi-User Engineering Scenarios

On multi-user engineering workstations, the corrupted tag may be locked by an active project session even after WinCC Runtime is stopped. To prevent this:

1. Disable the WinCC project sharing via SIMATIC Manager → Project → Remote → Disable Remote Access or by stopping the CCEngineering service.
2. Verify no engineering client has the project open by checking for a .lock file in the project folder.
3. If a .lock file is present and the original client is unreachable, delete the .lock file only after confirming no concurrent write activity.

Prevention: Tag Naming Standards

Tag naming should follow IEC 61131-3 conventions and the WinCC naming rules enforced by the editor. A robust standard looks like:

Enforce the standard through a project-specific Excel template that is the only authorized method for tag creation. The template is consumed by the WinCC Configuration Tool, which validates names against the standard before any commit to the SQL database.

Verification After Recovery

1. Open WinCC Explorer. Launch Tag Management and confirm the orphaned tag no longer appears in the tag list. Confirm no phantom structure rows appear in Project → Structure.
2. Open the WinCC project in Graphics Designer and search every .pdl file for any dynamic reference to the old tag name. Replace references with the corrected tag where necessary. Use Tools → Cross Reference to identify all consumers.
3. Recompile the project: Project → Compile → All. Confirm zero errors and zero warnings in the output window.
4. Start WinCC Runtime in test mode. Open WinCC Tag Simulator (Tools menu) and verify all retained tags function. Trigger any alarm associated with the affected area to confirm the alarm system is intact.
5. Run a SQL consistency check:

   -- Verify no orphan structure references remain
   SELECT COUNT(*) AS OrphanCount
   FROM dbo.MCPTVARIABLEDESC
   WHERE VARIABLENAME LIKE '%.%'
     AND STRUCTUREID NOT IN (SELECT STRUCTUREID FROM dbo.MCPSTRUCTURE);

   The result should be zero.
6. Document the change in the project's revision log, including the original corrupted tag name, the recovery method used, the operator who performed it, and the verification evidence.

Troubleshooting Matrix

Frequently Asked Questions