WinCC 7.4 Fixing Specified Table Does Not Exist Runtime Error

1. Problem Definition

The "Specified table does not exist" fault is a runtime-level SQL connectivity error reported by the WinCC V7.4 tag logging subsystem. The message originates from the ODBC layer when the WinCC runtime service attempts to query a configured tag logging segment (TLG) or alarm logging segment (ALG) and the referenced table cannot be located inside the SQL Server catalog. In a single-server WinCC station the event takes down tag logging on the server, which in turn causes the WinCC clients to lose all process values and historical trending data, even though the graphics continue to load.

Operators typically observe:

• Red/orange status icons in the WinCC Explorer tag logging editor indicating "no connection".
• Process value outputs in the graphics freezing at the last sampled value or being replaced by ####.
• The Tag Logging window inside WinCC Explorer showing an empty tag list even though the project has been started and the runtime database is mounted.
• Event log entries in the Windows Application log with sources WinCC_TLG, CCAgent, or ODBC reporting a state of HY000 (general error) or 42S02 (base table or view not found) for archives prefixed with CC_TLG_.

A project restart appears to recover operation temporarily, but the fault recurs on the next swap-in of the affected archive segment, the next scheduled archive change, or after a server reboot. This pattern is the principal indicator that the project is suffering structural damage rather than a transient connection drop.

2. Affected Versions and Software Stack

Reference the WinCC V7.4 System Description and the WinCC V7.4 SP1 Release Notes / Installation Notes on the Siemens Industry Online Support portal for the exact compatibility matrix applied to your environment.

3. Root Cause Analysis

Three independent failure paths can produce the same ODBC error string. Before applying any fix, determine which path applies to your system by inspecting the Windows Application log (eventvwr.msc) and the WinCC diagnostic files in <ProjectPath>\Diagnostics and <ProjectPath>\OPCHDA\Logs.

3.1 DCF (Database Configuration File) Corruption

The DCF file is the binary configuration record that maps logical archive names inside the WinCC project to the physical SQL Server tables. If the DCF file is deleted, truncated, or written inconsistently during a power loss, the runtime cannot resolve the configured archive names into table names and raises a "table not found" condition for every process tag. This is the most common cause on Windows Server 2008 R2 systems with unsecured UPS or abrupt shutdowns.

3.2 Orphaned or Detached SQL Database

WinCC stores tag logging in databases named CC_TLG_<ComputerName>, with one additional database per configured archive segment using the suffix _N (e.g. CC_TLG_SERVER1_1, CC_TLG_SERVER1_2). If one of these MDF/LDF files is missing from SQLServer\MSSQLxx.MSSQLSERVER\MSSQL\DATA, or if the SQL Server service is started before the volume containing these files is mounted, the database will not attach and the corresponding tables will be invisible to the WinCC runtime. Symptoms include the SQL Server Management Studio showing the database in (Recovery Pending) or (Suspect) state.

3.3 Configuration Mismatch After Hotfix / SP Install

Installing WinCC Service Packs or hotfixes while the runtime is active, or rolling back an SP without the matching project migration, leaves the project metadata at a version that disagrees with the binary layout of the archive. The DCF reads as valid but contains references to archive segment IDs that no longer match the SQL catalog. The tag logging editor in this case may not be empty, but specific archives fail to open.

4. Pre-Diagnostic Checklist

Complete these checks before opening a recovery session. They avoid corrupting the project a second time while it is being repaired.

1. Stop the WinCC Runtime on the server and on every connected client: WinCC Explorer → Computer → Stop Runtime or via the Autostart taskbar applet.
2. Stop the CCAgent service and the SIMATIC WinCC ArchiveConnector service to release any open file handles against the DCF file.
3. Take a file-level copy of the entire WinCC project directory (typically C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects\<ProjectName>) to a network share. This is the most important step — never modify the live project without a recoverable copy.
4. Use the WinCC Project Duplicator (Start → Siemens Automation → WinCC → Project Duplicator) to produce a complete, runtime-independent mirror of the project including the SQL databases. The Project Duplicator performs a structured copy with integrity checks and is the only Siemens-supported method for handing a project to engineering.
5. Verify the SQL Server MSSQLSERVER service is started and that the databases CC_TLG_<ComputerName> and CC_ALG_<ComputerName> are listed in sys.databases with state = ONLINE.

5. Resolution Path A — Regenerate the DCF Archive

This is the documented Siemens recovery procedure for DCF corruption. Reference the Siemens Support entry 109763043 — "How do you regenerate the WinCC Database Configuration File (DCF)?" for the canonical instructions.

1. Close WinCC Explorer and stop the WinCC Runtime. Confirm CCAgent.exe and ArchiveConnector.exe are no longer running in Task Manager → Details.
2. Navigate to the project path and locate the file <ProjectName>.dcf in the root of the project directory. Archive this file to a separate folder (do not delete it yet — keep it as a forensic reference).
3. Open WinCC Explorer on the server. The Tag Logging editor will appear empty; this is expected.
4. In WinCC Explorer, right-click Tag Logging and choose Open. The configuration tree is rebuilt from the SQL catalog the next time the editor opens, effectively writing a new DCF file.
5. If the tag list remains empty after step 4, close the editor, then delete the archived .dcf file from the project path, and re-open the Tag Logging editor. WinCC will detect the missing file and recreate it based on the current configuration stored in the registry hive HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Siemens\WinCC\<ProjectName>\Archive\TagLogging.
6. Restart the WinCC Runtime. Verify the Tag Logging editor now shows the configured tags and the OnError messages in the WinCC diagnostics toolbar disappear.

6. Resolution Path B — Reattach an Orphaned SQL Database

When SQL Server Management Studio shows the tag logging database in (Recovery Pending), (Suspect), or simply absent, the WinCC runtime cannot find any of its tables. Use the following SQL Server management sequence to reattach the database.

1. Open SQL Server Management Studio and connect to the WinCC instance (default: WINCC\WINCC or the named instance installed by the WinCC setup).
2. Right-click Databases → Attach…. Click Add… and browse to the missing MDF file. The default location is:

   C:\Program Files (x86)\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\CC_TLG_<ComputerName>.mdf

3. Confirm the LDF file path is correct in the Attach dialog. If the LDF is missing, tick the Remove column for the LDF row; SQL Server will create a new log file. Verify the database owner is WINCC (or the configured service account) before clicking OK.
4. If the database is in (Suspect) state, run the emergency mode sequence:

   ALTER DATABASE [CC_TLG_SERVER1] SET EMERGENCY;
   DBCC CHECKDB ('CC_TLG_SERVER1') WITH NO_INFOMSGS;
   ALTER DATABASE [CC_TLG_SERVER1] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
   DBCC CHECKDB ('CC_TLG_SERVER1', REPAIR_ALLOW_DATA_LOSS);
   ALTER DATABASE [CC_TLG_SERVER1] SET MULTI_USER;

   REPAIR_ALLOW_DATA_LOSS is destructive; restore from the most recent WinCC backup if available.
5. Open the WinCC Tag Logging editor. All configured archives should now be visible and the SQL database state should report ONLINE.

7. Resolution Path C — Project Duplicator Recovery

If neither DCF regeneration nor SQL reattachment produces a clean runtime, treat the project as fully corrupted and rebuild from the most recent known-good copy. The Project Duplicator is the sanctioned tool for this because it also moves the SQL databases atomically with the project files.

1. Start → Siemens Automation → WinCC → Project Duplicator.
2. Select Open project and browse to the most recent valid project backup or to a duplicate of the project that did not exhibit the fault.
3. Choose Duplicate project, then set the target path on a different physical disk to ensure the SQL write does not share I/O with the source.
4. During duplication, the Duplicator validates each archive segment. Allow it to complete; do not interrupt.
5. Activate the duplicated project and verify runtime. If runtime activates cleanly, archive the old project and proceed.

8. Configuration Verification

After applying any of the three resolution paths, perform the following verification steps before returning the system to production.

1. In WinCC Explorer, open Tag Logging and confirm the configured tag tree matches the engineering specification. Note the count under Statistics: Configured process tags should equal the engineering count.
2. Open the WinCC Online Trend Control on a test graphic and confirm historical values render for time ranges at least 7 days into the past.
3. Open the Windows Application log and clear it. Restart the WinCC Runtime. After 15 minutes of operation, search the Application log for sources CCAgent, WinCC_TLG, and ODBC; there should be no error-level events.
4. Run DBCC CHECKDB ('CC_TLG_<ComputerName>') and confirm the result is clean with no allocation or consistency errors.
5. From a WinCC client, open a process picture and confirm process values update in real time. Open the trend and confirm the value archive is being written (file size on the server's archive directory grows monotonically).

9. Prevention and System Hardening

10. Error Code Reference

11. When to Escalate

If the fault persists after completing Paths A, B, and C, gather the following artefacts and open a Siemens Technical Support ticket through the Siemens Industry Online Support portal:

• Complete project backup produced by the Project Duplicator (target path, not the source).
• SQL dump of CC_TLG_<ComputerName> and CC_ALG_<ComputerName> using Tasks → Generate Scripts → Script entire database and all database objects.
• The WinCC_Sys_<ComputerName>_<Timestamp>.log file from the Diagnostics folder.
• Windows Application log exported to .evtx covering the 24 hours before the fault.
• The exact version string from WinCC Explorer → Help → About and the SQL Server build number from SELECT @@VERSION.

Reference the WinCC V7.4 system documentation for the production-tested recovery procedures and the WinCC V7.4 SP1 installation notes for the platform prerequisites that must be in place before performing any of the recovery actions above.