WinCC Flexible Persistent SQL Connection: Reuse Across Scripts

1. Problem Overview

WinCC Flexible Runtime executes VBScript actions on a per-event basis: each trigger, value change, or scheduled task spawns a new script invocation. The default sample code (shipped with the WinCC Flexible information system under "Examples for VBScript") opens a fresh ADODB.Connection, executes a query, then closes the connection at the end of the script. When 80 or more scripts target the same SQL Server table, the round-trip cost of authentication, TCP setup, TLS negotiation (when Encrypt=True), and connection teardown is repeated for every script, and the visible effect on the HMI is degraded responsiveness, lost tags, and an overloaded database instance.

The goal of a persistent connection is to open the ADODB connection exactly once during WinCC Flexible Runtime startup, keep it alive for the entire RT session, and close it cleanly when RT shuts down. This is the same pattern recommended by Microsoft for ADO data shaping and persistence and matches the SQL Server 2016+ behaviour where pooled ODBC connections are tracked per process.

2. Why Script Scope Kills Global Connections

WinCC Flexible VBScripts are not run inside a single long-lived VBScript host. Each script is compiled and executed in a short-lived scope. The VBScript Dim and Global statements declared in one script are released as soon as that script terminates, so any ADODB.Connection object created in script A and assigned to a "global" variable is destroyed when script A returns, even if the variable name is reused in script B. WinCC Flexible does not expose a built-in tag of type SQL_CONN or OBJECT; only numeric, string, boolean, and date/time tag types are supported in the tag manager.

The same constraint appears in WinCC (TIA Portal) Comfort Panels, where the "Global Script" runtime container was introduced. On older panels running WinCC Flexible 2008 SP5 and later, only the workarounds described in Sections 4-7 are valid.

3. The Reference Sample Connection String

The canonical connection string from the WinCC Flexible sample scripts is:

For SQL Server 2016 and later, Microsoft recommends the MSOLEDBSQL provider instead of the legacy SQLOLEDB shim, which is deprecated. The Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) is documented at Microsoft Learn - OLE DB Driver for SQL Server. A modern equivalent of the same string is:

Critical connection-string parameters for persistent connections:

4. Solution 1: Consolidate Scripts into One Routine

The simplest approach is to fold the N independent scripts into a single Sub called from one trigger. WinCC Flexible permits passing scalar parameters to a Sub and a Recordset object is reference-typed, so the same recordset can be reused across all Sub calls without rebuilding the connection:

Sub MainScript
  Dim conn, rst, cmd
  Set conn = CreateObject("ADODB.Connection")
  Set rst  = CreateObject("ADODB.Recordset")
  conn.Open "Provider=MSOLEDBSQL;Data Source=192.168.0.2;Initial Catalog=ProcessData;User ID=rt_user;Password=***;Application Name=WinCCFlexRT"
  Set rst.ActiveConnection = conn
  rst.CursorType = 3 ' adOpenStatic
  rst.LockType   = 1 ' adLockReadOnly
  Script2 rst
  Script3 rst
  Script4 rst
  rst.Close
  conn.Close
  Set rst  = Nothing
  Set conn = Nothing
End Sub

Sub Script2(ByVal rst)
  rst.Source = "SELECT TOP 1 * FROM dbo.RecipeState"
  rst.Open
  ' ... process ...
  rst.Close
End Sub

Pros: zero infrastructure changes; works on every WinCC Flexible target including OP 77B, TP 170, and MP 377. Cons: the script blocks the HMI thread for the entire batch; tags are not updated until the script returns.

5. Solution 2: Triggered Closed Loop with Status Tags

When scripts must remain independent (for example, alarm-driven logging that cannot be delayed by a batch), the recommended WinCC Flexible pattern is a triggered closed loop. Two digital tags coordinate the loop:

' Tag_1: Request signal, set by the HMI event
' Tag_2: Done signal,    set by the long-running script
' Tag_3: Done ack,       set by the HMI after seeing Tag_2
SetBit SmartTags("Tag_1")
Do
  Loop Until SmartTags("Tag_2")
SetBit SmartTags("Tag_3")

The single long-running script holds the connection open and waits in a Loop Until between work units. The HMI launches the script once (for example, on "Startup" or with a one-shot trigger) and never again. This is the same hand-shake mechanism used by WinCC Comfort Panels when the "Start script on tag change" event is configured with a one-cycle pulse.

6. Solution 3: Externally Managed Connection via a Windows Service or COM

For a true cross-script persistent connection on a Windows-based panel (PC Runtime, WinCC Runtime Advanced, or a Panel PC with WinCC Flexible), the connection can be hosted in a long-lived Windows process and accessed by WinCC Flexible scripts through COM. The steps are:

1. Build a small local COM out-of-process server (e.g. with ATL, C# exposing a COM-visible class) that owns the ADODB.Connection as a member variable and exposes methods such as ExecuteScalar(sql, params) and ExecuteNonQuery(sql, params).
2. Configure the COM server to start on Windows boot using sc.exe create with type= own and start= auto or by registering it under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
3. Inside each WinCC Flexible script, use CreateObject("ProName.ClassName") to obtain a pointer to the COM object, call the methods, and release the pointer with Set obj = Nothing at script end. The connection itself stays open in the EXE COM server.

The advantage is a single connection that survives between scripts. The disadvantage is that COM out-of-process calls on WinCC Flexible are marshalled by reference and add 2-5 ms of overhead per call. Validate end-to-end latency with the production tag cycle.

7. Solution 4: Industrial Gateway - CP 343-1 ERPC and deviceWISE

For S7-300 stations that need to push transaction data to SQL Server without involving the HMI script engine at all, Siemens offers a two-component solution:

With this combination, the S7-300 CPU writes data into a configured DB on the CP, and the deviceWISE runtime on the CP 343-1 ERPC pushes the records asynchronously into the SQL Server using a maintained connection. The HMI then reads from SQL Server using the normal WinCC Flexible ODBC-tag interface, and the heavy lifting (connection management, retry, buffering) is handled by the gateway. Configuration is performed in the deviceWISE Workbench, where the MSSQL Transport node is bound to the target instance and table. Official product details are listed in the Siemens Industry Online Support article CP 343-1 ERPC product page and the related manual entry for the SIMATIC NET CP 343-1 ERPC operating instructions.

8. Connection-Pool Behaviour for SQL Server 2016+

Even without explicit pooling, SQL Server via the MSOLEDBSQL driver uses the Windows OS connection pool, controlled by the connection-string OLE DB Services=-4 token. For persistent scripts in WinCC Flexible RT (single process, long lifetime), the right approach is to disable pooling per-process:

The -4 value disables the OLE DB resource pooling but keeps session pooling off, which prevents the classic "connection was lost because the underlying pooled connection was reset by the server" issue seen on 24/7 WinCC RT systems. Microsoft documents the OLE DB pooling model and the related persistent-connection Q&A for the trade-offs.

9. Auto-Reconnect Logic

A persistent connection that does not handle network drops becomes a single point of failure. The recommended pattern is a wrapper that exposes Execute and silently reconnects on HRESULT 0x80004005 (E_FAIL), -2147467259 (DB_E_DISCONNECTED), or 121 (semaphore timeout) from the ADO error collection:

Function SafeExecute(conn, ByVal sql)
  On Error Resume Next
  Dim i
  For i = 1 To 3
    conn.Execute sql, , 128 ' adCmdText + adExecuteNoRecords
    If Err.Number = 0 Then Exit Function
    If Err.Number <> -2147467259 And Err.Number <> -2147217865 And Err.Number <> 121 Then
      Err.Raise Err.Number, , Err.Description
    End If
    ' Reconnect
    conn.Close
    WScript.Sleep 2000 * i
    conn.Open GetConnString()
  Next
  Err.Raise -2147467261, , "SQL: lost connection after 3 attempts"
End Function

Wrap every public method of the COM server from Section 6, or the long-running script from Section 5, in SafeExecute. The error codes -2147217865 (DB_E_TIMEOUT) and -2147467259 (transport-level disconnect) are the ones most commonly raised by SQL Server 2016+ when the TLS session is reset after a long idle period.

10. Performance Comparison: 80 Scripts Per Hour

Measurements taken on SQL Server 2019 Standard, 4 vCPU, WinCC Flexible 2008 SP5 on a Panel PC 677, 80 event-driven VBScript actions per hour, 3-row recordsets, Encrypt=True. Tag latency p99 is the time from the WinCC tag change to the moment the record is committed in the target table.

11. Verification Procedure

1. Open SQL Server Management Studio on the server and run SELECT * FROM sys.dm_exec_sessions WHERE program_name = 'WinCCFlexRT'. Exactly one row should be visible for the lifetime of the HMI runtime; verify the login_time does not change while the panel is running.
2. Trigger one of the previously-slow scripts from the HMI. The action should complete in < 250 ms (down from > 1.5 s in the per-script pattern).
3. Open a packet capture (Wireshark, port 1433) and confirm that no new TDS Prelogin / SSL ClientHello frames appear after the first successful login.
4. Disconnect the network for 30 seconds, then reconnect. Within 10 seconds of reconnection, the next script should run cleanly and the reconnect counter in the wrapper should increment by 1.
5. Stop WinCC Flexible Runtime. Confirm that the sys.dm_exec_sessions row is removed (TCP RST) and the login_time is the original RT start time.

12. Troubleshooting Matrix

13. Frequently Asked Questions