Wonderware InTouch SQL Configuration - The Actual Steps
Setting up InTouch to talk to SQL Server is one of those tasks that looks straightforward until you've spent six hours staring at a "Connection Failed" error that means absolutely nothing. The first thing to understand is that you're not just installing software. You're stitching together three separate things: the SQL Server instance, the InTouch SQL Gateway service, and the IIS web server that the Gateway runs on top of. Mess up any one of those pieces and the whole thing falls apart silently. Here's what the process actually looks like.
Prerequisites You'll Actually Need
You need SQL Server installed and running before you touch anything InTouch-related. This sounds obvious but I've seen people skip it. A named instance like SQLEXPRESS works fine for smaller setups, but production environments should run a full Enterprise or Standard edition. Make sure SQL Server Browser service is enabled if you're using a named instance, otherwise the connection string won't resolve. Install the correct ODBC driver. For SQL Server 2016 and later, use the Microsoft ODBC Driver 17. The old SQL Server Native Client drivers cause intermittent connection drops that will make you lose your mind. IIS needs to be present. The SQL Gateway registers as an ISAPI extension under IIS. On Windows Server 2019 and later, IIS doesn't come with all the necessary modules by default. You'll need to add the CGI feature through Server Manager or DISM. Without it, the Gateway installs but never starts properly.
Database Creation
Run the SQL scripts that come with the InTouch installation. They're usually located in the support directory under a folder called SQL Scripts or something similar. Execute them against your target database instance. This creates the tables, stored procedures, and views that InTouch uses for tag history, alarm logging, and trend data. The script creates a dedicated login and user. Do not skip changing the password from the default. Yes, it works with the default password. No, you should not use it in anything outside a test environment. I once had a security audit flag a production SCADA database because someone left the default credentials. That was a fun conversation.
Get the Full Details
SQL Gateway Service Installation
The SQL Gateway service is the core component. It acts as a bridge between the InTouch runtime and the SQL Server database. During the InTouch installation, there's typically a checkbox to install the SQL Gateway. If you missed it, you can run the setup again and choose Modify to add it later. After installation, the service is registered under IIS as a virtual directory. The default location is usually something like \InTouch\SQLGateway or \Wonderware\SQLGateway depending on your install path. The service name is typically Wonderware SQL Gateway or similar. Configure the database connection here. You'll enter the server name, database name, and the credentials from step one. Test the connection from this dialog before moving forward. If it fails, check two things: first, whether the SQL Server login has the correct permissions on the database, and second, whether the Windows account running the IIS application pool has network access to the SQL Server. The second one trips people up constantly because it's not an InTouch problem at all.
A Problem I Faced
On one project, the SQL Gateway would start successfully but any query against the alarm database returned a generic timeout. I spent about four hours checking firewall rules, SQL permissions, and service accounts. Nothing was wrong. The actual issue was that the IIS application pool was running under the DefaultAppPool identity, which couldn't authenticate to the SQL Server using Windows authentication. Switching the application pool identity to a dedicated domain service account and granting that account db_datareader and db_datawriter on the InTouch database resolved it immediately. I've hit this exact problem three times since then. Each time it took me about twenty minutes now instead of four hours. In the InTouch Application Watcher, you'll configure the SQL database settings under the Database menu. This is where you tell the runtime which SQL Server to use for tag history and alarms. Make sure the connection string matches exactly what you configured in the Gateway. Mismatched server names or database names between the Gateway and the Watcher are a common source of "it works on my machine" problems. The Archive Database service in the Watcher handles tag history. Enable it and point it at the same database. For alarm logging, there's a separate Alarm Database service. Run both if you need both features. Running only one is fine too, but don't expect trends to appear if you only configured alarms and vice versa.
Authentication Methods
InTouch supports both Windows authentication and SQL Server authentication for the database connection. SQL authentication is simpler to set up but less secure. Windows authentication requires the IIS application pool identity and the InTouch runtime process to run under accounts that have valid SQL Server logins. This is the recommended approach for anything beyond a standalone demo machine. One counter-intuitive point: Windows authentication often causes fewer problems in practice than SQL authentication, despite being more work to set up initially. SQL authentication credentials stored in configuration files are easy to compromise, and password expiry policies will break your database connection without warning. With Windows authentication, as long as the service account stays valid, the connection just keeps working.
Common Pitfalls
Firewall rules. SQL Server listens on port 1433 by default, but named instances use dynamic ports. If you're using a named instance, you need to either configure a static port for that instance or allow the SQL Server Browser service on UDP port 1437. Most people configure a static port and open just that one in the firewall. Named pipes versus TCP/IP. Make sure both protocols are enabled in SQL Server Configuration Manager. In rare cases, InTouch will fall back to named pipes if TCP/IP fails, and named pipes behave differently with certain network configurations. Having both enabled removes that variable. Service account privileges. The account running the SQL Gateway IIS application pool needs to be able to read the database. The account running the InTouch runtime needs the same permission. These can be different accounts, but they both need access. I once spent an afternoon troubleshooting because the Watcher ran under one user account and the Gateway under another, and only one had database permissions. The error messages pointed everywhere except the actual cause.
Validation
After everything is configured, generate some tag data and verify it appears in the SQL tables. Check the alarm tables too if you configured alarm logging. The tables will populate, but if they're empty after ten minutes of runtime activity, something is misconfigured. Check the Windows Event Log under Application and look for entries from the SQL Gateway source. The error details are usually cryptic but they contain enough information to narrow down the problem. Use the SQL Gateway diagnostics page at the IIS virtual directory to test connections directly. It's a simple HTML page that reports whether the Gateway can reach the database. It's faster than going through the Watcher interface.
Limitations
InTouch's built-in SQL historian is adequate for small to medium systems but doesn't scale well past a few hundred tags with high update rates. Once you exceed roughly 500 tags archiving at one-second intervals, you'll start seeing performance degradation in both the database writes and the historical data retrieval. At that point, consider Aveva's newer historian products or a third-party solution. For smaller installations under 200 tags with archival rates of five seconds or slower, the built-in SQL option works fine and saves you from buying additional software licenses. The SQL Gateway does not support real-time trending directly from the database efficiently. Querying decades of trend data through standard SQL SELECT statements is slow. Use the InTouch historian query tools rather than writing custom SQL for trend data retrieval. The custom query engine handles the compression and aggregation that makes large datasets searchable. Backup and restore of the InTouch SQL database follows standard SQL Server procedures. But be aware that the database schema is tightly coupled to the InTouch version. Upgrading InTouch often requires running schema update scripts on the database. Skipping those scripts during an upgrade is a reliable way to break alarm logging and historical trending without any obvious error messages until you actually need the data.
