Attaching Detached WinCC Tag Logging MDF Archive Segments and ValueID Reconciliation

Detached WinCC Tag Logging database segments (.mdf and .ldf files) must be reconnected by copying both paired files directly into the 'CommonArchiving' folder of the active WinCC OS project directory while WinCC Runtime is running. The Microsoft SQL Server WinCC instance dynamically attaches the segment and registers it with the Archive Manager. However, if tags were renamed or recreated during AS-OS compilation, WinCC assigns new internal ValueIDs. Because the WinCC Trend Control retrieves historical curves strictly by ValueID rather than tag string name, historical data will not appear until the historical segments' ValueIDs match the current tag logging configuration.

WinCC Archive Manager Architecture and CommonArchiving Function

WinCC Tag Logging stores cyclic and acyclic process values inside segmented Microsoft SQL Server databases. Each segment consists of an enterprise data file (*.mdf) and a transaction log file (*.ldf). The WinCC Archive Manager maintains a strict catalog of active and swapped-out (backup) segments.

Engineers frequently make the mistake of copying detached historical *.mdf files directly into ArchiveManager\TagLoggingFast or ArchiveManager\TagLoggingSlow. Doing so fails because SQL Server does not dynamically poll those subfolders for unattached files. Instead, WinCC provides a dedicated operational directory: <Project_Folder>\CommonArchiving. When WinCC Runtime is active, the WinCC DataManager continuously monitors CommonArchiving. When a valid matching *.mdf and *.ldf pair is copied here, SQL Server attaches the segment, establishes runtime database views, and exposes the data to WinCC Trend Controls.

The ValueID Disconnect Problem Following Tag Renaming

While copying segments into CommonArchiving attaches the database, it does not guarantee that historical curves will appear on operator trend displays. In WinCC, process value archives do not store tag names inside the individual time-stamped record rows. To optimize performance and storage, SQL Server rows store an integer identifier: ValueID.

When an engineer renames a CFC block, renames an output parameter, or deletes and re-imports an archive tag during AS-OS engineering compilation, WinCC removes the old archive tag definition and generates a brand new ValueID. When the operator opens a faceplate or trend window, the WinCC Trend Control requests data matching the current ValueID. Consequently, even though SQL Server contains gigabytes of historical data in the attached segment, the rows are tagged with the old ValueID, resulting in a blank trend curve prior to the reconfiguration date.

Diagnostic Mapping of Archive Tag ValueIDs in Microsoft SQL Server

The table below compares the internal database tables, file locations, and identifiers involved in Tag Logging segment attachment:

Database Component / FileLocation / Table NameFunctionReattachment / Recovery RoleCommonArchiving<Project_Folder>\CommonArchivingDedicated drop folder for runtime SQL segment attachment.Copy paired *.mdf and *.ldf here while WinCC Runtime is active.ArchiveManager\TagLoggingFast<Project_Folder>\ArchiveManagerDestination storage for fast cyclic process archives.Do not copy raw files here manually; managed automatically by WinCC.PDE#ArchiveTag / ArchiveTagProject Configuration Database (*RT.mdf)Maps tag strings (TagName) to internal integer ValueID.Consult this table via SQL Query to find old vs new ValueID.TagValues / TagArchiveSegment Archive Database (*_TLG_*.mdf)Stores historical time-stamped values: (ValueID, TimeStamp, Val).Target table where ValueID must match the current configuration.WinCC TrendControlWinCC Graphics Designer / FaceplatesRenders historical curves based on archive tag selection.Queries SQL Server using the active ValueID resolved from project metadata.

Step-by-Step Procedure to Attach Archive Segments and Restore Trends

Confirm Runtime Execution: Ensure WinCC OS Runtime is active on the Operator Station or OS Server.
Copy Paired Files to CommonArchiving: Locate the backup *.mdf and *.ldf files. Copy both files simultaneously into <WinCC_Project_Directory>\CommonArchiving. Monitor Windows Explorer: within 30 to 60 seconds, WinCC detects the files, attaches them to SQL Server, and removes them from CommonArchiving.
Inspect Active Segments in WinCC Explorer: Open WinCC Explorer (or examine SQL Server Management Studio under the WINCC instance). Confirm that database segment names appear under attached databases.
Reconcile ValueID Mismatch: If tag names were modified, connect to the SQL instance .\WINCC using SQL Server Management Studio. Query the project database configuration to identify the new ValueID assigned to the tag. In the historical segment database, update the old ValueID records to match the current ValueID:
sql UPDATE [SegmentDB].[dbo].[TagValues] SET ValueID = <New_ValueID> WHERE ValueID = <Old_ValueID>;
Refresh Trend Display: Open the WinCC Trend Control, select the target archive tag, and verify that continuous historical curves display across both historical and modern timeframes.

Verification

Verify segment integration through the following steps:
1. In SQL Server Management Studio connected to .\WINCC, execute sp_helpdb to verify that the historical archive database is listed with status ONLINE.
2. Open WinCC Runtime, launch the trend window for the affected process variable, and zoom out to encompass the date range of the attached segment: confirm smooth, uninterrupted trend curves.
3. Check the WinCC WinCC_Sys_01.log file in <Project_Folder>\Diagnostics: verify that segment attachment logged an informational confirmation with zero SQL return errors.

Limitations and Operational Precautions

Direct SQL table updates on active WinCC production databases must be performed with extreme caution. Always create a full project backup before executing manual SQL UPDATE scripts. Modifying database tables while write transactions are occurring can cause table deadlocks if index locks are escalated. Furthermore, segments generated on different major WinCC versions (e.g., WinCC V6.x vs V7.x) require database migration before they can be attached to modern SQL Server instances.