Fix WinCC V7.5 SP2 ODBC Connection Lost During Runtime Print Job

Siemens WinCC V7.5 SP2 reporting components rely on an ODBC DSN to query logged data from a local or remote SQL Server. Under certain runtime conditions, the print job invokes the ODBC connection while the underlying handle has already been torn down by either a server-side timeout, an ODBC driver housekeeping action, or a WinCC-internal resource release. The visible symptom is an intermittent report where every table body is replaced by the placeholder string ODBC Database. ODBC Table, while re-running the same print job immediately afterward returns correct data. Because the fault is non-deterministic and the WinCC diagnostic directory often shows no entries, the root cause must be identified through layered checks on the ODBC driver, the connection pool, the SQL Server session timeout, and the WinCC service pack level.

This article provides a complete field-engineering procedure for isolating and eliminating the ODBC Table error during WinCC reporting on V7.5 SP2, including version matrix, registry settings, DSN configuration hardening, ODBC driver selection, connection pooling mitigation, SQL Server wait_timeout-equivalent session parameters, and a recommended upgrade to WinCC V7.5 SP2 Update 19 (or the latest available cumulative update).

1. Problem Description and Observed Symptoms

The reported failure mode presents the following characteristics in a running WinCC Runtime project:

• Data logging via ODBC DSN into SQL Server functions normally. Records are written continuously without loss.
• WinCC Reporting invokes a print job that reads from the same SQL Server through the same DSN.
• On the first execution, the printed report displays the placeholder text ODBC Database. ODBC Table in every data region of every table.
• Re-issuing the same print job within seconds or minutes produces a fully populated report with no placeholder text.
• No errors are recorded in the \Siemens\Automation\WinCC\Diagnose log directory.
• No entries appear in the Windows Application or System event log that correlate with the print job timestamp.

The intermittent nature of the failure is the strongest diagnostic indicator. A hard fault (driver mismatch, DSN misconfiguration, 32/64-bit mismatch) would fail every print job. A consistent authorization or schema issue would also fail every print job. The non-determinism points to a session-lifecycle, pooling, or timeout interaction rather than a structural ODBC error.

2. Affected Versions and Software Stack

The following software matrix covers the confirmed affected and fixed configurations. Always confirm the installed versions through SIMATIC WinCC Explorer > Help > About and through SQL Server Management Studio > @@VERSION.

3. Root Cause Analysis

The intermittent ODBC Table placeholder is produced by the convergence of three independent failure surfaces. Each surface alone is not sufficient to break the print job; the combination produces a transient fault that resolves itself once the underlying condition resets.

3.1 Connection Pool Starvation or Stale Handle

The Windows ODBC Driver Manager enables connection pooling by default for SQL Server drivers that support SQLSetConnectAttr(SQL_ATTR_CONNECTION_POOLING). The WinCC Reporting component requests a connection from the pool, executes its query, and returns the connection. If the pool reuses a connection whose underlying TCP socket has been closed by the server (for example, because SQL Server reaped the session after its idle threshold), the next query against that pooled handle returns a connection failure with SQLState 08S01 (Communication link failure) or HY000.

Microsoft documents this exact behavior in KB 978a4bf3 (FIX: Setting of connection attribute fails when you use connection pooling for the SQL Server ODBC connection). The fix path described by Microsoft includes disabling connection pooling for the affected DSN, which eliminates the reuse of a stale socket but trades away the small performance benefit of pooling.

3.2 SQL Server Session Timeout

SQL Server terminates idle sessions based on a server-side timeout. The relevant parameters are:

• SQL Server: remote query timeout (default 600 s) — applies to queries initiated by a remote provider.
• SQL Server: query wait (default -1, unlimited) — controls the time a query waits for a lock.
• MySQL (used as analogy): wait_timeout (default 28800 s) — referenced in MySQL Bug 4869 where the client loses its connection after the server closes the idle socket and ODBC fails to reconnect automatically.

Although WinCC targets SQL Server, the architectural lesson is identical: when the server closes the socket, the ODBC layer does not transparently reconnect. The next consumer of the pooled handle (the WinCC print job) receives an empty rowset and the report prints the ODBC Table placeholder. Re-running the print job succeeds because the ODBC driver has now either obtained a fresh socket from the pool or has performed a reconnection attempt.

3.3 Reporting Thread vs. Logging Thread Synchronization

WinCC Reporting runs on a worker thread spawned by the WinCC Runtime. Continuous logging and cyclic archiving use a separate set of connections on the same DSN. Under load, the reporting thread may request a connection at the exact moment the logging thread has saturated the pool. With default pool size of 8 (driven by SQLSetConnectAttr(SQL_ATTR_MAX_POOL_SIZE)), this contention can cause the reporting thread to be handed a connection that is in the process of being recycled.

3.4 WinCC Service Pack and Update Level

Siemens ships cumulative ODBC stability fixes in WinCC V7.5 SP2 Update packages. The WinCC V7.5 SP2 Update 16 release baseline is known to exhibit the conditions described in this article on certain ODBC Driver 17 revisions. Update 17, 18, and 19 contain adjustments to the reporting engine's connection acquisition and release ordering. The Siemens support entry 109793460 - WinCC V7.5 SP2 Update 19 lists the closed defect categories.

4. Diagnostic Procedure

Before applying any fix, capture the current state so that the fix can be verified against a known baseline. The following procedure collects every data point required to confirm the root cause and to rule out a structural defect.

1. Open WinCC Explorer > Help > About and record the exact build string of WinCC, Simatic Logon, and Simatic Audit. Compare to the matrix in section 2.
2. Open SQL Server Management Studio, connect to the SQL Server instance, and run:

   SELECT @@VERSION AS SqlServerVersion;
   SELECT name, value, minimum, maximum, value_in_use, is_dynamic, is_advanced
   FROM sys.configurations
   WHERE name IN ('remote query timeout', 'query wait', 'user connections', 'max worker threads');
   SELECT
     session_id, login_time, host_name, program_name, login_name, status, cpu_time, memory_usage,
     last_request_start_time, last_request_end_time, reads, writes
   FROM sys.dm_exec_sessions
   WHERE program_name LIKE '%WinCC%' OR program_name LIKE '%ODBC%';
   

3. Open ODBC Data Sources (32-bit) from %windir%\SysWOW64\odbcad32.exe on a 64-bit Windows installation. WinCC V7.5 SP2 is a 32-bit application and uses the 32-bit ODBC Administrator regardless of host OS. Verify the DSN name, driver (must be ODBC Driver 17 for SQL Server or SQL Server Native Client 11.0), and target server.
4. Enable ODBC tracing:
   1. Open odbcad32.exe, switch to the Tracing tab.
   2. Set Machine-Wide tracing (WinCC services run under SYSTEM, NETWORK SERVICE, or a dedicated user, so a machine-wide trace is required to capture their calls).
   3. Set the log file path to a dedicated directory with at least 2 GB free space. ODBC traces grow rapidly.
   4. Click Start Trace Now.
5. Reproduce the fault by triggering the failing print job three to five times. Note the timestamp of each attempt.
6. Stop the trace and analyze the .log file. Search for SQLState 08S01, HY000, Communication link failure, Connection is broken, and the SQLDisconnect / SQLFreeConnect sequence that immediately precedes each failing SQLExecDirect.
7. Cross-check the Windows event log under Applications and Services Logs > SQL Server and under System for entries around the same timestamps.
8. Inspect %ProgramFiles%\Siemens\Automation\WinCC\Diagnose\WinCC_Sql_*.log for any SQL_ERROR line numbers.
9. Record the SQL Server session IDs observed in step 2 before and after the fault. If the session IDs are identical and the last_request_end_time precedes the print job login_time, the report thread is reusing an aged session.

5. Solution: Layered Mitigation

Apply the following mitigations in order. Each step is independently sufficient for some sites; combining them provides robust, fault-tolerant operation.

5.1 Update WinCC to the Latest Cumulative Update

The first and lowest-risk action is to apply the latest WinCC V7.5 SP2 cumulative update. The support entry 109793460 lists each update package and its closed defects. To install:

1. Close WinCC Runtime and WinCC Explorer.
2. Stop the WinCC services:

   net stop "CCAlgCSHandler"
   net stop "CCArchiveManager"
   net stop "CCMsgQueue"
   net stop "CCODBCTracer"
   net stop "CCPerfMon"
   net stop "CCProjectManager"
   net stop "CCRTLoader"
   net stop "CCScheduler"
   net stop "CCSysdiag"
   net stop "CCUAStartManager"
   net stop "CCWriteFastServer"
   

3. Run the cumulative update installer with administrator rights.
4. Reboot the station.
5. Validate by re-running the print job 20 times and counting ODBC Table occurrences. The expected count after the update is zero.

5.2 Disable ODBC Connection Pooling for the WinCC DSN

Following the Microsoft fix pattern documented in KB 978a4bf3, disable connection pooling for the specific DSN used by WinCC. This eliminates the use of stale pooled handles entirely.

1. Open SysWOW64\odbcad32.exe.
2. Switch to the Connection Pooling tab.
3. Uncheck Use the SQL Server connection pooling for the WinCC DSN. If only a global toggle is available, uncheck it and rely on per-driver settings via the registry (see 5.3).
4. Click OK and restart the WinCC Runtime services.

5.3 Configure Pooling via the Windows Registry

When WinCC runs as a service under a non-interactive account, the GUI toggle in odbcad32.exe may not survive service re-installation. Configure pooling behavior through the registry to make the change persistent:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ODBC\ODBCINST.INI\ODBC Driver 17 for SQL Server\Pooling]
"CPTimeout"=dword:0000003c
"DisablePooling"=dword:00000001

Key values:

• CPTimeout (DWORD): Connection pool timeout in seconds. A value of 0x3c (60 s) matches the SQL Server default remote query timeout and prevents the pool from retaining stale handles longer than the server's idle reaper.
• DisablePooling (DWORD): Set to 1 to disable pooling for this driver. Set to 0 to leave pooling enabled but governed by CPTimeout.

For SQL Server Native Client 11.0 (SQLNCLI11), the equivalent keys are under ...\SQLNCLI11\Pooling with the same value names.

5.4 Configure SQL Server to Match the Client Timeout

Adjust the SQL Server configuration so that idle session reaping never occurs while the WinCC client still expects a valid handle:

EXEC sp_configure 'remote query timeout', 0;  -- 0 = no timeout
RECONFIGURE;

A value of 0 disables the remote query timeout entirely. Combined with a properly sized CPTimeout on the client, this guarantees that the server never closes an idle socket while the client believes the connection is still valid.

If setting remote query timeout to 0 is not acceptable in your environment, the alternative is to set it to a value strictly greater than the longest expected reporting query duration plus the CPTimeout value. For example, with a CPTimeout of 60 s and an expected maximum reporting query of 120 s, set remote query timeout to at least 180 s.

5.5 Use ODBC Driver 17 for SQL Server

The Microsoft ODBC Driver 17 for SQL Server resolves several connection-reuse and token-handling defects that affect Driver 13 and Native Client 11. The Hasura issue 9227 documents the symptom [Microsoft][ODBC Driver 17 for SQL Server]The connection is broken, which is the same SQL Server fault class observed in this WinCC scenario. Migrating to Driver 17 produces more deterministic error messages and, in many cases, eliminates the silent rowset failure that produces the ODBC Table placeholder.

To migrate:

1. Install Microsoft ODBC Driver 17 for SQL Server (both x86 and x64 installers; WinCC is 32-bit, but the x64 driver is required for any 64-bit tools that share the same SQL Server).
2. Open SysWOW64\odbcad32.exe and edit the WinCC DSN to change the driver to ODBC Driver 17 for SQL Server.
3. Test the connection from the dialog and from a WinCC test project before deploying to production.

5.6 Add a Connection Retry Wrapper in the WinCC Report Layout

For sites that cannot apply the registry change immediately, configure the WinCC Report Designer layout to invoke a validation query before the main dataset. This forces the ODBC driver to detect a stale handle and re-establish the connection before the data query runs.

1. Open the affected report layout in WinCC Report Designer.
2. Insert a dynamic table bound to the SQL query SELECT 1 AS ConnectionProbe.
3. Set the table's Visible property to No. The query still executes, exercising the ODBC connection, but no data is rendered.
4. Position the probe table as the first data region in the layout so it executes before all other tables.

This is a workaround, not a root-cause fix. The probe forces a connection re-establishment on every print job, which eliminates the visible symptom but does not address the underlying pool behavior. Apply one of the other mitigations in parallel.

6. Step-by-Step Resolution Procedure

The following consolidated procedure resolves the fault on a typical WinCC V7.5 SP2 Upd 16 station with a local SQL Server 2017 and the ODBC Driver 17 for SQL Server.

6.1 Prerequisites

• Administrative access to the WinCC station.
• Administrative access to the SQL Server instance (local or remote).
• WinCC V7.5 SP2 installation media or download access for the latest cumulative update.
• Microsoft ODBC Driver 17 for SQL Server (x86) installer.
• Backup of the WinCC project database and the SQL Server logging database.

6.2 Procedure

1. Stop the WinCC Runtime and all WinCC services (see command list in section 5.1).
2. Apply the latest WinCC V7.5 SP2 cumulative update (Update 19 or later, per Siemens support entry 109793460). Reboot.
3. Install or update the Microsoft ODBC Driver 17 for SQL Server to the latest release.
4. Open SysWOW64\odbcad32.exe and edit the WinCC DSN:
   1. Change the driver to ODBC Driver 17 for SQL Server.
   2. Test the connection. Confirm the test succeeds under both the interactive user and the WinCC Runtime service account.
5. Apply the registry change in section 5.3 to disable pooling for the Driver 17 instance, or configure CPTimeout to match the SQL Server remote query timeout.
6. On the SQL Server, set remote query timeout to 0 (no timeout) or to a value that exceeds the longest reporting query plus the client CPTimeout.

   EXEC sp_configure 'remote query timeout', 0;
   RECONFIGURE;
   

7. Add the connection probe (section 5.6) to any report layouts that have exhibited the fault. This protects against any residual pool reuse during the transition period.
8. Start the WinCC Runtime services.

6.3 Verification

1. Trigger the previously failing print job 20 times in succession. The expected outcome is 20 successful reports with no ODBC Table placeholders.
2. Trigger the print job once after a 30-minute idle period. Confirm the report still renders correctly. This validates that the timeout alignment eliminates the stale-handle condition.
3. Trigger the print job during a peak logging interval (when the data logging rate is at its maximum). Confirm the report renders correctly. This validates the connection pool starvation mitigation.
4. Open the ODBC trace (re-enable for verification only, then disable) and confirm that no SQLState 08S01 or HY000 errors are emitted during the print job.
5. Query sys.dm_exec_sessions and confirm that the session ID used by the print job is freshly established (a new login_time within the last few seconds) rather than reused from the pool.

7. Driver and Architecture Notes

7.1 Why the WinCC Diagnostic Folder is Empty

The WinCC\Diagnose directory only captures errors emitted through the WinCC internal logging API. When the ODBC driver manager returns a connection error directly to the WinCC Reporting engine, the engine treats the empty rowset as a data condition rather than an error, and no entry is written to the diagnostic log. This is by design: WinCC Reporting is a query tool, and an empty rowset is a valid data condition. The diagnostic log silence is therefore expected and is not evidence that the system is healthy.

7.2 Why the Windows Event Log is Silent

The ODBC driver manager and the SQL Server ODBC driver do not always raise a Windows event log entry on a connection-level error. The error is returned through the ODBC call stack to the application, not surfaced to the OS event subsystem. The Windows event log is therefore a useful but not exhaustive source of evidence.

7.3 32-bit vs. 64-bit ODBC Administrator

WinCC V7.5 SP2 is a 32-bit application. On a 64-bit Windows host, the 32-bit ODBC Administrator resides at %windir%\SysWOW64\odbcad32.exe, and the 64-bit administrator at %windir%\System32\odbcad32.exe. Configuring the DSN in the wrong administrator is the single most common cause of ODBC Table errors that are not intermittent but consistent. The intermittent nature of this case rules out the 32/64-bit mismatch as the primary cause, but it should still be verified as part of the diagnostic procedure.

7.4 Simatic Logon and Simatic Audit Interaction

Simatic Logon v1.6 and Simatic Audit v7.5 SP2 share the WinCC service host. A version mismatch can produce credential propagation failures that manifest as silent ODBC errors when the reporting thread attempts to acquire a connection under the wrong security context. Always match the Simatic Logon and Simatic Audit versions to the WinCC service pack level.

8. Alternative Configurations and Edge Cases

8.1 Remote SQL Server

When SQL Server runs on a remote host, add a Windows Firewall rule that allows inbound TCP 1433 (or the custom port) from the WinCC station, and confirm that the SQL Server Browser service is running if a named instance is used. A network-level silent socket closure is functionally equivalent to a server-side idle timeout and will produce the same ODBC Table symptom.

8.2 Named Instance with Dynamic Port

If the SQL Server is a named instance using a dynamic port, the ODBC DSN must specify the port explicitly or the SQL Server Browser service must be reachable. A transient failure of the browser service can produce intermittent ODBC failures. Hardcode the port in the DSN configuration to remove the dependency.

8.3 SQL Server Always On Availability Groups

On Always On AG listeners, the MultiSubnetFailover parameter must be set to True in the ODBC connection string. The ODBC Driver 17 supports this parameter natively. Without it, AG failover events produce silent connection drops that manifest as the same ODBC Table symptom.

Driver={ODBC Driver 17 for SQL Server};Server=tcp:AGListener,1433;
Database=WinCC;MultiSubnetFailover=Yes;TrustServerCertificate=Yes;

8.4 WinCC V8 and Later

WinCC V8 (TIA Portal-based configuration) uses a different reporting engine and a different ODBC layer. The mitigations in this article apply in principle, but the specific registry keys and service names differ. Refer to the WinCC V8 documentation for the current update package and the V8-specific service names.

9. Troubleshooting Matrix

10. Safety and Operational Considerations

• Always back up the WinCC project database and the SQL Server logging database before applying service packs or driver updates.
• Test the ODBC connection from the service account that runs the WinCC Runtime services, not just from the interactive administrator account. The two contexts may have different DSN visibility and different credential sets.
• Schedule service pack and driver updates during a planned maintenance window. The WinCC station will be offline during the update.
• Do not disable connection pooling globally on a station that hosts multiple applications. Use per-driver or per-DSN settings to limit the impact to WinCC.
• After any change, monitor sys.dm_exec_sessions for one hour to confirm the session lifecycle is behaving as expected.

11. Field Commissioning Checklist

1. WinCC V7.5 SP2 Update 19 (or latest) installed and verified.
2. Simatic Logon and Simatic Audit versions match the WinCC SP level.
3. ODBC Driver 17 for SQL Server (x86) installed and selected for the WinCC DSN.
4. ODBC pooling disabled or CPTimeout ≤ 60 s for the WinCC driver.
5. SQL Server remote query timeout = 0 (or ≥ CPTimeout + max report query time).
6. ODBC DSN configured in SysWOW64\odbcad32.exe (32-bit) and tested under the WinCC service account.
7. Connection probe added to all report layouts that have exhibited the fault.
8. Print job executed 20 times consecutively with no ODBC Table occurrences.
9. Print job executed after 30-minute idle period with no ODBC Table occurrences.
10. Print job executed during peak logging interval with no ODBC Table occurrences.
11. ODBC machine-wide trace disabled after verification.

FAQ