Querying Infohub from SQL

The supported read surface: the v* views#

Infohub's schema ships a set of views that exist precisely to be read from outside:

A minimal externally-run value query looks like:

SELECT Value, Quality, PeriodStart, PeriodEnd
FROM   vMeasureValue
WHERE  MeasureID = @id
  AND  PeriodStart >= @from AND PeriodEnd <= @to

Three rules make this durable:

1. Read the views, never the base tables. MeasureValue and friends carry versioning, archiving, and slicing mechanics; the views resolve all of that (preferred version, current value) so you do not have to — and the base tables are the part the product reshapes between versions.
2. Read-only, always. Any external write to Infohub's tables is unsupported and genuinely dangerous — the engine's bookkeeping (versions, watermarks, slice chains) assumes it owns the data.
3. Key on IDs, resolve names via vMeasure. Names change; IDs don't (within an instance).

The _Deprecated views are your upgrade insurance#

Alongside several views sit _Deprecated twins (vMeasureValue_Deprecated, vMeasure_Deprecated, vEventPeriod_Deprecated, …). That naming is the versioning policy: when a view's shape must change, the old shape is preserved under the deprecated name for a transition period rather than vanishing outright.

What that means operationally:

• If an upgrade breaks your query against vSomething, check for vSomething_Deprecated — your old shape is probably there, and repointing buys time to migrate properly.
• Equally: anything of yours still reading a _Deprecated view is living on borrowed time. The deprecated shape exists to be removed in a later release. Migrate to the current view and treat the deprecated one as a bridge, not a home.
• The historical incident that motivates this article — external queries failing after a 7.1.x upgrade because "the view was removed" — is exactly this lifecycle experienced without warning. Inventory your external queries before upgrades and re-verify them after (add it to the upgrade checklist).

Mapping questions the views answer#

• "Which MeasureID is this chart showing?" — vMeasure by name/folder; or the Config tool shows IDs directly.
• "Why is a day blank on the dashboard but rows exist in the table?" — you are likely reading a base table and seeing non-preferred versions or slice fragments; vMeasureValue returns what the dashboard logically shows. If the view is also blank for the period, the value genuinely does not exist — a processing question, not a query question.
• "Event data with attributes for my BI tool" — join vEventPeriod to vEventPeriodAttributeValue on the event period; filter Preferred to the current version.

When direct SQL is the wrong tool#

Reading the views is fine for reports and reconciliation. Three cases deserve the purpose-built mechanism instead:

• Continuous export to another system → a data consumer (watermarking, restatement, retries — all solved there).
• Interactive dashboards elsewhere → the Flow Server REST API returns chart-shaped data with security applied; direct SQL bypasses Infohub's group scoping entirely.
• Anything that writes → there is no supported case. Manual values enter through forms; corrections through the product.

That security point deserves emphasis: SQL access ignores Infohub's group model. A read-only SQL account for reporting is a bypass of content scoping by construction — grant it deliberately, to systems rather than curious users.

Housekeeping for external consumers#

Keep a one-page register of every external query/tool touching the Infohub database: which views, which columns, owned by whom. It turns "did the upgrade break anyone?" from an unanswerable into a checklist — and it is the document that would have prevented the incident this article exists because of.

See also#

• Database Maintenance
• Consumer Placeholder Reference
• Users, Groups, and Access
• Upgrading to Flow 7.2.0