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.