WinCC Flexible SQL Logging Stops After 1-2 Hours: Troubleshooting

1. Problem Overview

WinCC Flexible PC Runtime is widely used for HMI / SCADA visualization in machine and process monitoring. When configured to log tag values to a Microsoft SQL Server database through ODBC, the runtime normally writes each value change to the configured table through the configured data source. A common field failure is that logging works for approximately 1 to 2 hours after Runtime start and then silently stops, while the WinCC Runtime display continues to update without any alarm. The process values are visible on screen, but no further rows are inserted into the SQL table.

This is a particularly difficult fault to detect because the HMI surface does not indicate any logging error, the OPC server is not the cause, and the SQL Server itself remains reachable. File-based logging on the same project usually works correctly, which isolates the fault to the ODBC / database layer that is added when the user switches the log target from File to Database.

2. Environment and Configuration Baseline

The reported failure is consistent across several hardware layouts:

• WinCC Flexible 2008 SP5 Runtime, PC-based, single station (or distributed with OPC).
• Microsoft SQL Server 2005 / 2008 / 2008 R2 / 2012 / 2014, either Express or Standard edition. The Siemens WinCC Flexible SQL database reference documents that Microsoft SQL Server 2005 Express Edition is installed alongside WinCC Flexible 2008 by default.
• ODBC data source configured through the 32-bit ODBC Administrator (because WinCC Flexible is a 32-bit application and the SQL Server ODBC driver is loaded from %WINDIR%\SysWOW64\odbcad32.exe on 64-bit Windows).
• Logging mode set to Circular logging in WinCC Flexible with target = Database.
• Tags configured with Log on change of value.

Before changing anything, document the current state of the project so the change can be rolled back. Capture a screenshot of every dialog in Project > Logs > Properties, the ODBC DSN, and the SQL Server configuration.

3. Root Cause Analysis

Five distinct root causes reproduce the 1-2 hour stop window, in order of probability in the field:

1. SQL Server Auto Close is enabled on the target database. When Auto Close is ON, SQL Server releases the database and closes all connections after the last user disconnects. WinCC Flexible opens a connection on first write, the application holds it open only while it is actively writing, and if a quiet period is encountered (e.g. no tag changes) the database is closed. The next write fails and WinCC Flexible does not reconnect.
2. ODBC driver version mismatch or known driver defect. Newer Microsoft ODBC Driver 17 / 18 for SQL Server introduces Encrypt and TrustServerCertificate connection-string attributes that older WinCC Flexible code paths do not pass. The connection succeeds, runs, then drops on the first TCP idle timeout. See SCCM 2403/2509 ODBC Driver 18.6.1 failure (Microsoft Q&A) for the typical error class.
3. SQL Server user connections cap reached. SQL Server Express defaults to a low value for user connections in some configurations, and the instance-level setting is consumed by every short-lived WinCC connection. Each reconnect attempt exhausts the pool until the cap is hit.
4. TCP keep-alive and SQL Server remote query timeout. A firewall, switch, or anti-virus product silently drops the TCP session after 60-120 minutes of idle, and WinCC Flexible does not implement application-level keep-alive on the logging connection.
5. Circular log size exhaustion not visible in the WinCC dialog. If the tag triggers a write at a high rate, the segmented / circular log can fill the configured maximum and stop without a popup alarm in older service packs.

4. ODBC Driver and Connection Layer

WinCC Flexible is a 32-bit COM-based application. On 64-bit Windows (Windows 7 / 10 / 11 IoT, Windows Server 2008 R2 / 2012 R2 / 2016 / 2019 / 2022) the ODBC data source must be created with the 32-bit ODBC Administrator:

Verify the bitness of the WinCC process in Task Manager > Details > Platform column. The value must be 32-bit for the matching DSN to be used.

Configure the data source as follows:

When the driver is ODBC Driver 17 for SQL Server or ODBC Driver 18 for SQL Server, append the following attributes to the connection string in WinCC Flexible (where supported) or set them as DSN defaults:

If Encrypt=Yes is required and the SQL Server certificate is not trusted by the client, the connection will succeed for the first write, then fail on reconnect with a TLS handshake error after the TCP session is recycled. The ODBC trace utility (odbccp32.cpl > Tracing) will record SSL Provider: The certificate chain was issued by an authority that is not trusted or hex state 08001 / 08006 immediately before the silent stop.

5. SQL Server Configuration

Open SQL Server Management Studio (SSMS) and verify the following on the target instance:

1. Right-click the target database > Properties > Options > Auto Close = False.
2. Right-click the target database > Properties > Options > Auto Shrink = False (recommended).
3. Right-click the server > Properties > Connections > User connections = 0 (unlimited) or a value greater than the expected number of WinCC clients plus 50.
4. Right-click the server > Properties > Connections > Remote query timeout = 0 (no timeout) or a value greater than the longest expected quiet period between writes.
5. SQL Server Configuration Manager > SQL Server Network Configuration > Protocols for MSSQLSERVER > TCP/IP > Properties > IP Addresses tab > TCP Dynamic Ports = blank for default instance, fixed for named instance.
6. Windows Firewall inbound rule: TCP 1433 (default instance) or the dynamic port used by the named instance must be open from the WinCC Runtime host.

To check Auto Close programmatically:

To disable Auto Close:

6. WinCC Flexible Tag Logging Configuration

Open the WinCC Flexible project, navigate to Project > Logs, open the log properties, and verify the following parameters:

The WinCC Flexible documentation explicitly states that database logging uses an internal buffer; when the database connection is lost, the buffer fills, logging is paused, and the application continues to operate. This matches the reported behaviour: the Runtime display continues to update, but no new rows are written to SQL.

Verify the tag configuration under Project > Tags for each logged tag:

• Acquisition mode: Cyclic continuous or On change.
• Logging: On change of value with optional On limit violation.
• Limit values: confirm upper and lower limits are not stuck at the boundary, which would cause constant writes and quickly fill the log.

7. Circular Log vs. Segmented Log

The user reported Circular logging is enabled. With circular logging, WinCC Flexible overwrites the oldest entries when the configured maximum is reached. The fault is therefore not a buffer-full condition by itself. If a high write rate is expected, set the log to Segmented (Daily / Weekly / Monthly) and the storage location to File for long-term archive, while Database remains the live target. This dual-target strategy is supported in WinCC Flexible 2008 and later service packs.

To confirm whether the buffer is the stop cause, enable the WinCC Flexible diagnostic trace:

1. Close WinCC Flexible Runtime.
2. Open Start > Programs > Siemens Automation > WinCC Flexible > Tools > WinCC Flexible Diagnosis.
3. Activate Logging and ODBC Trace.
4. Restart Runtime and reproduce the 1-2 hour window.
5. Review the generated log file under %USERPROFILE%\Siemens\WinCC Flexible\Logs for the keyword ODBC or SQL_ERROR.

8. Step-by-Step Diagnostic Procedure

Use this ordered procedure on a live system. Each step is non-destructive unless explicitly marked.

1. Open ODBC 32-bit Administrator: %WINDIR%\SysWOW64\odbcad32.exe. Click Configure on the DSN used by the project, then Test Data Source. The test must return SUCCESS.
2. Open SSMS and run SELECT @@VERSION on the target instance. Record SQL Server build, e.g. Microsoft SQL Server 2014 (12.0.6024) - 64-bit.
3. Run SELECT name, is_auto_close_on, is_auto_shrink_on, state_desc FROM sys.databases WHERE name = 'YourDB'. Verify is_auto_close_on = 0.
4. Run SELECT @@MAX_CONNECTIONS. The result must be greater than the number of WinCC clients + 50. If 0 is returned, unlimited.
5. Open SQL Server Profiler (or Extended Events session sqlserver.login, sqlserver.logout, sqlserver.connectivity_ring_buffer_recorded) and watch the WinCC host. Count the number of Login / Logout events for the WinCC user. If a new login occurs roughly every 1-2 hours, the application is reconnecting and the prior session was dropped.
6. Enable ODBC tracing via 32-bit ODBC Administrator > Tracing > All the time (for production only; otherwise One-Time). Reproduce the failure. Inspect SQL.LOG in the configured log directory. Look for SQLDisconnect without a subsequent SQLConnect until the next runtime restart, or for error states in the form [SQLSTATE]=[08001] [Native Error].
7. In WinCC Flexible, switch the log target from Database to File and confirm that logging continues for > 24 hours. This isolates the fault to the ODBC / SQL layer and rules out the tag acquisition path.
8. Switch back to Database. Capture the time of the first successful insert and the time of the last. The delta is the stop interval.
9. Restart the SQL Server service and the WinCC Runtime, then re-run the test. If the failure interval changes (shorter or longer), the root cause is on the SQL Server side (Auto Close, Auto Shrink, memory pressure, instance restart).

9. Resolution Path and Configuration Changes

Apply the following configuration changes in this order. Verify after each step.

Step A: SQL Server side

ALTER DATABASE YourDB SET AUTO_CLOSE OFF;
ALTER DATABASE YourDB SET AUTO_SHRINK OFF;
EXEC sp_configure 'user connections', 0; RECONFIGURE;
EXEC sp_configure 'remote query timeout', 0; RECONFIGURE;

Reboot SQL Server service. Confirm with SELECT is_auto_close_on FROM sys.databases WHERE name = 'YourDB'.

Step B: ODBC driver pinning

If the DSN currently uses ODBC Driver 17 for SQL Server or ODBC Driver 18 for SQL Server, replace it with the SQL Server Native Client 11.0 (SQLNCLI11) driver. This driver ships with SQL Server 2012 and is compatible with WinCC Flexible 2008 SP5. It does not enforce TLS by default and avoids the encryption / certificate handshake issues documented in the Microsoft ODBC 18 install failure thread.

To switch the driver:

1. Open odbcad32.exe from SysWOW64.
2. Remove the existing DSN.
3. Add a new System DSN with driver SQL Server Native Client 11.0.
4. Configure the server, authentication, and default database as before.
5. Click Test Data Source. Expected: SUCCESS.

Step C: WinCC Flexible project

Open the project, navigate to Logs > Properties, select the same DSN name, save, and transfer / restart Runtime. Verify the first write succeeds and the second write is observed in the SQL table within the configured acquisition cycle.

Step D: Operating system and network

• Disable any anti-virus real-time scan on the WinCC process and the SQL Server data files.
• On Windows Firewall, allow inbound TCP 1433 (default instance) or the named instance port for the SQL Server service account.
• On network switches and routers, raise the TCP idle timeout above 2 hours for the WinCC host <-> SQL Server host pair.

10. Verification and Monitoring

After each configuration change, run a 4-hour verification window:

1. Start the WinCC Runtime.
2. Record the time of the first row insert into the target table: SELECT TOP 1 TimeStamp FROM YourSchema.YourLogTable ORDER BY TimeStamp DESC;
3. Every 5 minutes, run: SELECT COUNT(*) AS rows_inserted, MAX(TimeStamp) AS last_write FROM YourSchema.YourLogTable;
4. Confirm that last_write advances monotonically and that the row count grows.
5. Capture the SQL Server wait statistics delta over the window: SELECT * FROM sys.dm_os_wait_stats WHERE wait_type LIKE 'OLEDB%' OR wait_type LIKE 'ASYNC_NETWORKIO%';

A successful resolution yields a last_write that is within one acquisition cycle of the current system time at every checkpoint, for the full 4 hours, and beyond.

11. Field-Commissioning Best Practices

When commissioning a new WinCC Flexible project that logs to SQL, follow this checklist:

• Always use the 32-bit ODBC Administrator (SysWOW64\odbcad32.exe) to create the DSN. Document the driver version, server name, authentication method, default database, and connection-string overrides.
• Pin the ODBC driver to SQL Server Native Client 11.0 for new installations to avoid TLS / certificate drift.
• Disable Auto Close and Auto Shrink on every target database that receives HMI / SCADA writes.
• Set the SQL Server user connections to 0 (unlimited) or to a value that accounts for all expected clients + headroom.
• Set remote query timeout to 0 on the server.
• Use a dedicated SQL login for WinCC with the minimum required permissions (db_datawriter on the target schema only).
• Add a daily SQL Server Agent job that archives the logging table to keep the live table small.
• Schedule a Windows Task on the WinCC host that restarts the WinCC Runtime service once per day during a maintenance window, as a belt-and-braces guard against any application-level connection leak.
• Keep WinCC Flexible 2008 SP5 fully patched; the latest hotfix resolves several ODBC reconnect bugs documented in the Siemens Knowledge Base.
• Plan migration to TIA Portal WinCC for new projects. The WinCC Flexible 2008 SQL database PDF remains the authoritative reference for the legacy API.

12. FAQ