Get Industrial SQL Data into Excel
Excel's Power Query can connect to SQL Server. Industrial systems store data in SQL. Getting plant data into a workbook sounds like a two-minute job. The friction is where the SQL server lives, who can reach it, and what it costs the production system when analysts start querying it directly.
If you've already tried something and hit a wall, the list below is probably why. The barriers aren't obvious until you're in the middle of them.
Why it's hard
Seven reasons the SQL → Excel path is harder than Power Query makes it look.
The SQL server is on a restricted network — each analyst machine needs access
Industrial SQL databases — backing historians, MES platforms, alarm systems, or SCADA — typically live on the OT network or a separate operational VLAN. Getting Power Query to reach the server requires a network path from each analyst's machine, which usually means VPN configuration, firewall rules, or a dedicated OT-to-IT bridge — coordinated per user, per machine.
Credentials are shared — the same username and password on every machine
Industrial SQL databases rarely use individual accounts. A single shared credential gets passed to each analyst, saved in their Power Query connection settings, and stored in their workbook. When the password is rotated — or when someone leaves — every workbook across the team breaks at once. There's no audit trail and no way to revoke access for an individual user.
Raw SQL data doesn't mean anything without context
Industrial SQL schemas are built for the application that writes them, not for analysts. Alarm records reference numeric event codes. Production entries reference measurement point IDs. Tag data uses internal identifiers nobody outside the OT team recognises. Making a Power Query pull actually useful requires joining multiple tables and knowing enough about the plant to make the mappings — knowledge that's rarely documented.
High-frequency raw data at full resolution crashes Excel
Industrial SQL tables accumulate fast — sub-minute records for every tag, every alarm, every production event. Even a few weeks of raw data for a handful of measurements can run to millions of rows. Excel locks up on refresh, pivot tables become unresponsive, and files become too large to share. Pre-aggregating the data in Power Query M requires SQL knowledge that most analysts don't have.
Every workbook refresh adds load to a server running a production application
The SQL server is already busy writing production data for the historian, MES, or SCADA system it backs. When multiple analysts refresh their workbooks — especially with heavy aggregation queries over long time ranges — they compete with the application for server resources. Timeouts, slow application response, and eventually hardware upgrade pressure are the result.
Excel for the Web can't connect to SQL on a private network
Excel on the web — in SharePoint Online, Teams tabs, or a browser — can't reach SQL Server instances on private OT or operational networks. Any workbook built on a Power Query SQL connection is desktop-only. It won't refresh in the browser, can't be opened as a live shared workbook in Microsoft 365, and breaks the moment it leaves the analyst's local machine.
Schema changes in the source system break Power Query silently
When the OT or application team updates the database schema — renaming a column, changing a data type, adding a table — Power Query queries that worked yesterday fail silently or return wrong data. Analysts are rarely notified when the source system changes. A broken workbook is discovered when someone opens it and finds error values where numbers used to be.
The approaches teams usually try
Three common paths — and where each one runs into trouble.
Power Query direct SQL connection per analyst
Set each analyst up with a Power Query connection to the SQL server — network access arranged by IT, shared credentials distributed, and workbooks built against the raw tables. The most direct path and the one most teams start with.
The catch: Every analyst machine needs its own network path and credential configuration. Workbooks don't work in Excel for the Web. Refreshes hit the production server directly. Schema changes break workbooks across the team at once. And there's no central place to define what the data means — each analyst writes their own context lookups, inconsistently.
Shared flat-file exports to a network folder
Have someone — usually a developer or the OT team — run a scheduled SQL query and export the results to CSV or Excel on a shared network drive. Analysts build workbooks against the exported files instead of the live database.
The catch: The export pipeline needs to be built and maintained. The data is always stale by one export cycle. Analysts can't query different date ranges or change the aggregation without going back to whoever manages the exports. And the shared drive still needs to be accessible from every analyst machine.
Database views built by the OT or application team
Ask the OT or application team to create pre-joined, pre-named SQL views that analysts can query instead of the raw tables — reducing the schema knowledge required and simplifying Power Query.
The catch: This puts the OT team in the critical path for every reporting change. Views need to be kept up to date with source schema changes. It still doesn't solve network access, credential management, server load, or Excel for the Web. And the people you're asking to build views are usually the same people who are trying to run the plant.
How TrendOps solves it
TrendOps Edge connects to the SQL database on the local network, queries it on a schedule, maps the data to context, and forwards it to TrendOps Platform in the cloud over outbound MQTT. TrendOps Link — a Microsoft 365 Excel add-in — surfaces that data in any workbook, desktop or web, with no direct SQL connection required.
TrendOps Edge handles the SQL connection locally. Analysts use TrendOps Link to pull data from the cloud — no network path to the OT SQL server, no per-machine credential configuration.
The shared SQL credential lives in one place — the TrendOps Edge configuration. Analysts authenticate to TrendOps with their own accounts. Rotating the SQL password means updating one configuration, not chasing down every workbook across the team.
TrendOps Edge queries on a schedule and caches results in the cloud. Workbook refreshes hit TrendOps Platform — not the production SQL server. No resource contention, no risk of slowing the application, no capacity upgrades driven by reporting load.
Configure TrendOps Edge to join lookup tables, resolve alarm codes, and map measurement point IDs to descriptive names — once, centrally. Every analyst's workbook gets the same clean, contextualised data without duplicating the mapping logic.
TrendOps Link is a Microsoft 365 web add-in. It works wherever Excel does — desktop, browser, SharePoint Online, Teams. Workbooks can be shared and refreshed without requiring any special network access from the recipient.
Set the query interval to match your reporting needs. TrendOps normalises high-frequency data before it reaches Excel — keeping row counts workable and workbook refreshes fast.
SQL data from your MES or alarm system lands in TrendOps Platform alongside data from AVEVA PI, DeltaV, FactoryTalk, and any other connected source. One TrendOps Link connection surfaces all of it — no separate query per system.
TrendOps Edge pushes data to the cloud over a single outbound MQTT connection. No inbound firewall exceptions on the restricted network — the SQL server stays unreachable from the outside.
What you end up with
Industrial SQL data in any Excel workbook — desktop or web — without direct SQL access, shared credentials, or load on the production server.
Desktop, browser, SharePoint, Teams — TrendOps Link works wherever Excel does.
Edge queries on a schedule; workbook refreshes never reach the production SQL server.
IDs resolved, context mapped, and frequency normalised before Excel touches it.
SQL credentials stay on the Edge; analysts authenticate with their own accounts.
Your analysts shouldn't need a path to the production SQL server every time they refresh a workbook
TrendOps moves industrial SQL data to the cloud cleanly — so any analyst can work with it in any Excel workbook, without touching the source system.
Book a Demo