Skip to content

Fluke MET/CONNECT

MET/CONNECT is Fluke's MET/TEAM-less delivery of the same MET/CAL database. Fluke's own installation guide puts it this way: MET/CONNECT lets you use MET/CAL without carrying the overhead of the MET/TEAM asset management software — third-party systems pull the calibration results through a slim REST API or a file export.

For calServer this means: MET/CONNECT is connected exactly like MET/TEAM. Same connection, same provisioning, same automatic two-way sync. It is not a second integration but a variant of the same sync instance.

Why this works

Both products sit on the same database schema:

MET/TEAM MET/CONNECT
Tables (Assets, CallSheets, CallSheetResults, ToolAssignments, …) present present
Native spl_* procedures calServer calls present present
AuditLog2, AssetSync created by calServer created by calServer
DB version line up to 3.4.0 same line, up to 3.8.0
Own application UI yes no

This is not taken on trust: the nightly integration run drives the same test suite against both products, using the sample databases from their respective installation media. Details in MET/TEAM test database.

Setup

Requirements

  • A reachable MET/CONNECT database on Microsoft SQL Server 2016 or newer (MET/CONNECT's own requirement).
  • A SQL Server login allowed to create procedures, tables and triggers — provisioning installs the sync interface into the MET/CONNECT database. db_owner covers everything.
  • The database name. The MET/CONNECT installer asks for it during setup; the default is metconnect.

Creating the instance

  1. Open Administration → Extensions → Fluke MET/TEAM.
  2. Click New instance, give it a name (e.g. "Calibration lab") and pick MET/CONNECT as the product.
  3. On the Connection tab enter server, port, username, password and database, then Test connection.
  4. On the Synchronisation tab choose what is synced (inventory, calibrations, results) and provision.

From here on nothing is product-specific: the sync runs through the same scheduled tasks as MET/TEAM (metteam:pull and metteam:push, every 15 seconds), the same outbox and the same diagnostics.

Existing instances stay MET/TEAM

An instance without an explicit product is treated as MET/TEAM. That covers every installation that existed before the distinction — nothing changes there.

Changing the product of an existing instance

On the Connection tab via the Product field. The setting drives no sync logic, only how the far side is named in the UI, diagnostics and error messages. Changing it therefore does not require re-provisioning.

What MET/CONNECT does not have

MET/CONNECT ships no UI of its own in which a user could review the synced data — that is precisely the point of the product. To check what calServer wrote, look in calServer itself, in the diagnostics (Tools tab) or directly in the database.

The MET/CONNECT REST API (default ports 6381/6382) is unaffected and can keep running alongside. calServer does not use it: it is read-only, and the two-way sync needs direct database access.

Re-provision after a Fluke database upgrade

This applies to MET/TEAM just as much, but comes up more often with MET/CONNECT because its schema line keeps moving: Fluke replaces the Assets and CallSheets tables wholesale during a database upgrade (DROP TABLE and rebuild rather than ALTER TABLE). The calServer triggers attached to them disappear with the tables — Fluke does not know about them and does not restore them.

So after every Fluke database upgrade: Synchronisation tab → provision. Until then the inbound sync stands still, because the AuditLog2 change queue stops being fed. Diagnostics (Tools tab) list the missing triggers.

Fluke's own upgrade notes predict the same: a customised database — explicitly including additional indexes — may be rendered unusable by the upgrade script.

Troubleshooting

Identical to MET/TEAM — see Fluke MET/TEAM → Troubleshooting. Diagnostics name the product of the instance in question, so a MET/CONNECT instance reports "MET/CONNECT is not reachable" rather than a MET/TEAM that is not installed at the customer at all.

One case is worth calling out: if diagnostics report missing native procedures (spl_Assets_INSERT and neighbours), it is almost always the login's permissions rather than the product. SQL Server only lists objects a login holds some permission on — both products ship these procedures.

Background

The decision to build MET/CONNECT as an instance variant rather than a second integration, including the rejected alternatives: ADR 2026-08-13.