Sooner or later someone needs historian data somewhere the historian's own trend tool cannot reach, in an Excel model, a Power BI dashboard, or a SQL report that mixes process data with business data. The common bridge for that is ODBC, which lets those tools query the historian as if it were a database and receive results as ordinary rows of timestamp, value, and quality. It is powerful and convenient, but it is also the easiest way to accidentally ask for far more than you meant. This how-to explains how to connect, how to choose between raw and interpolated retrieval, how to bound a query by tag, time, and interval, and how to keep a careless query from scanning the whole archive.
Historian export over ODBC in one line: To export historian data over ODBC you connect a tool such as Excel, Power BI, or a SQL client to the historian's ODBC or SQL interface, then issue a query that names the tags, a start and end time, and, for evenly spaced output, a sampling mode and interval. The historian returns tabular rows of timestamp, value, and quality that the tool can load directly. The key discipline is to always bound the query by specific tags and a specific time range, and to pick raw mode for exact samples or interpolated mode for a fixed-interval grid, so a request never turns into a full-archive scan.
The typical trouble with an ODBC export is not that it fails but that it runs for a very long time, returns millions of rows, or bogs down the historian for everyone else. The usual cause is a query that is under-constrained: it omits a time range, so the historian tries to return all of history; it omits specific tags, so it sweeps across the entire tag set; or it asks for raw samples on a fast tag over a wide window, which can be enormous. A second common cause is choosing raw retrieval when the report actually wanted values on a regular grid, so the tool pulls a mountain of unevenly spaced points and then struggles to align them.
A related symptom is a report whose numbers do not line up across tags because each tag was sampled at whatever moments it happened to change, so a raw export has different timestamps in every column. People often react by post-processing in the spreadsheet, when the real fix is to ask the historian for interpolated values at a shared interval so every tag lands on the same timestamps. Recognizing whether you need exact recorded samples or a regular time grid up front avoids both the performance problem and the alignment problem.
There are also connection-level symptoms worth naming: a driver that will not authenticate, a query that returns quality codes nobody expected, or timestamps that appear shifted because the client and server disagree on time zone. These are configuration issues rather than query-shape issues, but they show up at the same moment and are easy to confuse with a slow query, so it helps to confirm the connection and a tiny bounded test query work before blaming the export size.
Start by deciding the retrieval mode, because it changes everything downstream. Raw mode returns the actual stored samples with their real timestamps, values, and quality, which is right when you need exactly what was recorded, for an audit or a detailed investigation, but it produces irregular timestamps and can be voluminous for fast tags. Interpolated or sampled mode returns a value at each point on a fixed interval you specify, such as every minute or every hour, which is right for reports and BI where you want an evenly spaced series and consistent timestamps across tags. Some interfaces also expose aggregate modes that return a statistic per interval, which is the most compact option when you only need averages or totals.
Then bound the query on both axes. Always name the specific tags you want rather than selecting broadly, and always supply an explicit start and end time, because an open-ended range is what turns a query into a full scan. For interpolated or aggregate modes, set the interval deliberately: an hourly interval over a month is a few hundred rows per tag, while a raw pull of a per-second tag over the same month is millions. If you are prototyping, run the query over a single day first to confirm the shape and volume, then widen the window once you know how many rows you will get.
The columns you receive are usually a timestamp, the value, and a quality indicator, and you should carry the quality through rather than dropping it. Quality tells the report consumer whether a value was good, interpolated, or came from a period with problems, and discarding it can make bad data look authoritative. Pay attention to time zone as well, since the historian may store in a reference time such as UTC while the report is expected in local time, and confirm how the driver presents timestamps so the exported hours mean what the reader assumes.
A reliable procedure looks like this. First, install and configure the ODBC or JDBC driver the historian provides and create a data source that points at the server with the right credentials, then verify it with a trivial query that returns a single tag over a single hour. Second, decide raw versus interpolated versus aggregate based on whether the consumer needs exact samples, an even grid, or per-interval statistics. Third, write the query naming the exact tags, an explicit start and end, and, for grid or aggregate modes, the interval. Fourth, run it over a small window to check row count and column meaning, including quality and time zone, before expanding to the full range.
For anything that runs more than once, save the query rather than rebuilding it by hand each time, and parameterize the time range so the same query can be re-pointed at a new period without editing its structure. Power BI and Excel can hold the connection and refresh it, which is convenient, but be deliberate about the refresh window so a scheduled refresh does not silently start pulling an ever-growing range. If a report needs a rolling window such as the last thirty days, express that as a relative range in the query so the volume stays bounded as time passes.
In a SCADA and cloud monitoring context, ODBC export is often how process data reaches the business side, feeding allocation, KPI dashboards, and management reporting that live outside the control system. Because those consumers can trigger heavy reads, it is good practice to point exports at a secondary copy or a mirror when one exists, so a large BI refresh does not compete with live collection on the primary. Treating exports as bounded, tag-specific, time-bounded queries, run against the right server, keeps the historian responsive while still getting the data where the rest of the organization needs it.
Use raw mode when you need the exact samples that were recorded, with their real timestamps and quality, such as for an audit or a detailed investigation. Use interpolated or sampled mode when you want an evenly spaced series at a fixed interval, which is what most reports and BI dashboards need because it puts every tag on the same timestamps. Aggregate modes are best when you only need per-interval statistics like averages or totals, since they return the fewest rows.
Almost always because it is under-constrained. Omitting a time range makes the historian try to return all of history, omitting specific tags sweeps the whole tag set, and pulling raw samples for a fast tag over a wide window produces millions of rows. Bound the query by explicit tags and an explicit start and end, use an interpolated interval instead of raw where you can, and test over a single day before widening the range.
That is usually a time zone mismatch between how the historian stores time and how the driver or client presents it. Many historians store in a reference time such as UTC, and if the report expects local time, the exported hours can look shifted. Confirm how your ODBC driver and client handle time zone, and align the query and the consuming tool so the timestamps mean what the reader assumes.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.