Architecture

The Connector exposes M‑Files metadata through a dedicated SQL Server database and a lightweight .NET wrapper around the M‑Files API.

Core components

  • LSConnect wrapper assembly (wraps Interop.MFilesAPI) to read/write vault data.

  • T‑SQL procedures and functions that synchronize metadata and object details bidirectionally.

  • A single Connector database per vault (deploy one DB per vault if you need to serve multiple vaults).

Deployment model

  • The Connector installs into its own SQL Server database. SQL Server may be on the same host as M‑Files Server or on another server as long as network connectivity exists.

  • Cloud vaults connect to SQL via the Web API.

  • The Connector does not require or use the internal M‑Files vault database (SQL or Firebird); it operates a separate and independent database.

Version 5

Before version 5, the connection from M‑Files to SQL was optional and used mainly to trigger operations from the M‑Files client; most activity originated from SQL to M‑Files.

Version 5 adds user‑facing operations and automation—available in the vault administration module (workflow state actions, event handlers) and in the MFSQL Connector dashboards (desktop and web)—which require a connection from the vault to SQL Server. This connection is provided via ODBC or the Web API.