Resolving WinCC V7 Tag Logging "No Data Connection Could Be Established" After Project Duplication

1. Problem Statement

After copying a fully functional WinCC V7.0.2 SCADA project from a source PC to a target PC using the built-in Project Duplicator, the runtime starts, graphics update, alarms fire, and the connection to the PLC works, but the Tag Logging subsystem silently fails. The Online Trend Control and Online Table Control report:

"No data connection could be established"

and the trend area remains blank. Every Tag Logging configuration flag in the WinCC Explorer is set, the Runtime (RT) is started, and both PCs are confirmed to run the same WinCC V7.0.2 with the same Microsoft SQL Server version. Critically, a brand-new WinCC project on the same target PC logs tags without error, which proves the installation is healthy. The defect is therefore project-specific, not environment-specific, and the root cause sits in the duplicated project artifacts.

2. Technical Background: How WinCC V7 Stores Tag Logging

WinCC V7 separates graphics, alarms, and tag logging into different internal databases. Tag Logging uses a pair of SQL Server databases per project:

The Runtime reads and writes these databases through the WinCC Archive Manager service. The service registers each archive at project activation using the absolute path that was current when the project was first activated on the source PC. When you copy the project to a different PC or to a different drive letter / user profile, those absolute paths become invalid. WinCC then cannot mount the archives and reports a broken data connection on every Online Trend / Online Table Control.

This is the single most common cause of the "No data connection" error after a project copy, and it is invisible until the Runtime attempts to start the archive subsystem.

3. Root Cause Analysis

Five failure modes account for almost every occurrence of this error after duplication. They are listed in order of statistical frequency in field reports.

3.1 Stale Absolute Archive Paths

The source PC stored archives at, for example, C:\WinCC_Projects\MyPlant\ArchiveManager\TagLogging\CC_TLG_MyPlant.mdf. After Project Duplicator, the target PC has the project at D:\SCADA\MyPlant\... but the SQL Server still references the C:\ location. The Archive Manager cannot find the primary database file (MDF) and aborts connection.

3.2 SQL Server Login / Ownership Mismatch

The duplicated MDF/LDF files retain the original SQL Server login SID of the source machine. When the target SQL Server attempts to attach the database, the SID resolution fails, and the database is marked SUSPECT or simply does not attach. WinCC then has no archive to connect to.

3.3 Tag Logging Runtime Flag Not Active

WinCC Tag Logging has an independent start/stop flag in the Computer properties. If the flag is cleared during duplication (or was never set on the target), the Archive Manager service does not initialize archives even though all other RT components start. Graphics and alarms continue working, masking the issue.

3.4 Project Duplicator Version Mismatch

Project Duplicator must match the source and target WinCC version exactly (including service packs and hotfixes). A V7.0.2 source duplicated to a V7.0 target, or vice versa, produces a project where Tag Logging XML descriptors reference schema versions the target cannot interpret.

3.5 Windows User / UAC / Folder Permissions

The ArchiveManager subfolder inherits permissions from the project root. If the target PC is launched under a different Windows user, or if UAC redirected the project write path to a virtualized location, the SQL Server service account (typically NT AUTHORITY\SYSTEM or a local user) cannot create or extend the transaction log.

4. Pre-Diagnosis Checklist

Run these checks before making changes. They isolate which of the five root causes applies.

1. Open WinCC Explorer > Tag Logging on the target PC. Confirm the configured archives appear in the tree without red icons.
2. Open Computer > Properties > Startup tab. Verify Tag Logging Runtime is checked. (This is the "start/stop RT flag" referenced in maintenance advisories.)
3. In Windows, open Services (services.msc) and confirm SQL Server (WINCC) and WinCC Archive Manager are Running and set to Automatic.
4. Open SQL Server Management Studio (SSMS), connect to localhost\WINCC, expand Databases. Look for entries starting with CC_TLG_. If the database shows (Suspect) or is missing, root cause 3.2 applies.
5. Right-click the CC_TLG_<ProjectName> database > Properties > Files. Compare the Path column to the actual project location on disk.
6. Compare WinCC build numbers: Help > About on both PCs. Build numbers must be identical (e.g., both 7.0.2.0 + same HF). Mismatched build = root cause 3.4.
7. Right-click the project folder in Windows Explorer > Properties > Security. Confirm the SQL Server service account and the logged-in user have Modify rights on ArchiveManager\TagLogging.

5. Step-by-Step Resolution

The procedure below addresses all five root causes in a single safe pass. Total time: 15-30 minutes for a medium project.

Step 1 — Stop the WinCC Runtime

On the target PC, in WinCC Explorer, click Runtime > Stop. Wait for the status bar to show Runtime stopped. This releases the SQL lock on the archive databases.

Step 2 — Detach Stale Tag Logging Databases

1. Open SQL Server Management Studio, connect to the WinCC instance (localhost\WINCC with Windows authentication).
2. Right-click CC_TLG_<ProjectName> > Tasks > Detach. Tick Drop Connections and confirm.
3. Repeat for CC_TLG_F<ProjectName> if it exists.

Step 3 — Correct the Database File Paths

1. In Windows Explorer, browse to the project folder: <ProjectPath>\ArchiveManager\TagLogging\.
2. Confirm the .mdf and .ldf files are physically present and sized > 0 bytes. If only an LDF exists, the MDF was lost during copy.
3. In SSMS, right-click Databases > Attach. Click Add and select the .mdf file at the correct local path.
4. SSMS will warn if the LDF path is wrong. Edit the LDF row to point to the local LDF and click OK.

Step 4 — Reset SQL Server Ownership

After attaching, run the following in a new SSMS query window (substitute your project name and local service account):

USE CC_TLG_<ProjectName>;
GO
EXEC sp_changedbowner 'sa';
GO
USE CC_TLG_F<ProjectName>;
GO
EXEC sp_changedbowner 'sa';
GO

This resets the database owner to sa, eliminating SID mismatches from the source PC.

Step 5 — Confirm the Tag Logging Runtime Flag

In WinCC Explorer on the target PC, navigate to Computer > right-click > Properties > Startup tab. Tick Tag Logging Runtime if cleared, click Apply, then OK. Restart the Runtime.

Step 6 — Re-Activate the Project

WinCC V7 re-registers the archive paths on every RT activation. Click Runtime > Start. Open the Online Trend Control. The "No data connection" error should be replaced by live process values within a few seconds.

6. Alternative: Manual Project Migration

If the above does not resolve the issue, the most robust fix is to abandon Project Duplicator for tag logging and rebuild the archives manually. This is the method Siemens technical support uses when escalated.

1. On the source PC, open Tag Logging editor. File > Export all archive configurations to a .tlg file.
2. Copy the WinCC project to the target PC using Project Duplicator excluding the ArchiveManager subfolder.
3. On the target PC, open Tag Logging editor. File > Import the .tlg file.
4. Start Runtime. WinCC will recreate the CC_TLG_ databases from scratch at the new local path.
5. Accept the loss of historical data, or restore the original MDFs into the new path using Steps 2-4 above.

This approach guarantees that all paths in the project are relative to the target machine.

7. Project Duplicator Best Practices

To prevent recurrence on future migrations, follow these rules.

• Match versions exactly. Both source and target must have the same WinCC major, minor, service pack, and hotfix level. The Duplicator performs no cross-version conversion.
• Use matching Windows user accounts. The Duplicator preserves Windows ACLs from the source. If the target user is different, grant the new user the SIMATIC HMI and SQL Server sysadmin rights before the first RT start.
• Place projects on the same drive letter. Although Project Duplicator rewrites most internal paths, third-party add-ons (e.g., custom C scripts) often hardcode C:\. Using C:\WinCC_Projects\ on both PCs avoids edge-case failures.
• Deactivate Runtime before duplicating. Copying an open MDF produces a corrupted file. Always stop RT on the source before running Project Duplicator.
• Re-activate on the target. Do not assume the duplicate is "ready to run." Always stop and re-start the Runtime after the first copy.

8. Verification Procedure

After applying the fix, confirm the repair with these checks.

1. Online Trend Control: Open a trend view in graphics runtime. Values should appear within one acquisition cycle (typically 1-5 seconds for 1 s tags).
2. Online Table Control: Open the table view. Rows should populate with current values and a continuous timestamp.
3. SQL Server Management Studio: Query the archive:
   SELECT TOP 10 * FROM CC_TLG_<ProjectName>.dbo.PDT_<ArchiveName> ORDER BY TimeStamp DESC;
   Rows should be returned.
4. WinCC Diagnostics Window: Tools > Diagnostic > Runtime. There should be no red entries under Tag Logging.
5. Disk write test: Wait for the configured archive size to grow. Verify the LDF file size increases, proving active logging.
6. Reboot test: Restart the PC and re-launch Runtime. Archives should auto-mount without manual SQL intervention. If they do not, repeat Step 3.

9. Common Error Variants and Their Fixes

10. SQL Server Configuration Reference

WinCC V7.0.2 ships with SQL Server 2005 Express by default. The instance name is WINCC. Connection uses Windows authentication. The relevant connection string is built by the WinCC Archive Manager at startup and uses Named Pipes or TCP/IP on port 1433 (instance dynamic port if SQL Browser is running).

Registry path storing the SQL instance: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\WINCC\MSSQLServer with value LoginMode = 2 (mixed mode not required; Windows auth preferred). Do not change this manually.

The Tag Logging configuration files that store archive definitions are located in the project at:

• <Project>\TagLogging\TLGConfig.xml — archive definitions
• <Project>\ArchiveManager\ArchiveList.xml — runtime mount list

These files contain no absolute paths and are safe to copy. The .mdf / .ldf files are the only artifacts whose paths are environment-dependent.

11. When to Escalate to Siemens Technical Support

Escalate if any of the following remain after applying the full procedure above:

• The CC_TLG_ database attaches but immediately goes Suspect on every RT start.
• The Tag Logging editor refuses to open with a license or schema error.
• The project was originally created on WinCC V6 and upgraded, and the archive structure is incompatible.
• Microsoft SQL Server error log shows Error: 9003, Severity: 20, State: 1 (invalid log scan) or Error: 823 (I/O error).

Before contacting support, collect: the WinCC version and build number, the SQL Server build, the contents of C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\ERRORLOG, and a screenshot of the Tag Logging editor tree on the target PC.

12. Related Context: WinCC Unified RT Logging

Engineers migrating from WinCC V7 to WinCC Unified RT should note that the data logging model is fundamentally similar — process values are collected into a database for analysis and error documentation — but the storage engine is SQLite-based and the archive configuration is integrated into the TIA Portal project. The duplication issues described here are largely eliminated because the path is always project-relative. The troubleshooting principles (verify archive location, verify runtime activation, verify service health) are unchanged and apply to both product generations.

FAQ