Roadmap

This page captures planned and proposed changes for the MFSQL Connector — the themes we are working on, the problems we intend to address, and the areas we are still investigating.

Important

Forward-looking statement. The items on this page describe work under consideration, not committed product. Nothing described here is available today, and any item may be amended, deferred, or dropped entirely at the sole discretion of Laminin Solutions, without notice. Do not base a purchasing decision, project plan, or upgrade commitment on anything on this page — base it on functionality available in the current release.

Changes that have actually shipped are recorded in Version Control — Release 5.

If a particular change or feature matters to your environment, email support@lamininsolutions.com. Customer input genuinely shapes what we prioritise, though raising an item is not a commitment that we will build it.

Themes and scope

  • Operations and processing improvements (bulk, reliability, performance)

  • M-Files Configurations as the primary configuration surface

  • Reporting, observability, and usability

  • Installation and setup streamlining

  • Payload format and performance changes

Operations and processing

Context

MFSQL Connector up to version 4 used multiple overlapping routines for metadata operations and auditing.

Gaps to address

  • Add rollback support for multi-object operations.

  • Reduce check-out/check-in churn; support true bulk operations where safe.

  • Detect sync errors earlier; add retry when an object is checked out/locked.

  • Process only changed objects where possible.

  • Strengthen error handling and telemetry.

  • Move from XML payloads to JSON for larger/cleaner data structures.

Main operations model

  • Core SQL areas: Class Tables, Change History, Audit History.

  • Direction: 1 = MF→SQL, 0 = SQL→MF.

  • Scope: single class, multiple classes, or all classes.

  • Actions: create, edit, delete, undelete.

  • Deletion handling: optionally retain deleted object details in class tables.

  • Selection: all objects, a supplied list, or filtered by date (and user as a subset filter).

  • Guardrails: ensure audit history, objver, and objid state is current before write operations.

  • Delta detection: update only changed rows/columns where applicable (see e.g. https://www.mssqltips.com/sqlservertip/6497/how-to-identify-which-sql-server-columns-changed-in-a-update/).

Procedure consolidation candidates

Reduce overlap by consolidating or refactoring procedures around the operations model. Candidate list:

  • spMFUpdateTable

  • spMFUpdateMFilesToMFSQL

  • spMFUpdateTableinBatches

  • spMFTableAudit

  • spMFUpdateObjectChangeHistory

  • spMFDeleteObject

  • spMFUnDeleteObject

  • spMFDeleteObjectList

  • spMFDeleteAdhocProperty

  • spMFDeleteObjectVersionList

  • spMFGetObjectvers

  • spMFObjectTypeUpdateClassIndex

  • spMFRemoveAdditionalProperties

  • spMFUpdateAllncludedInAppTables

  • spMFUpdateItemByItem

  • spMFUpdateTableWithLastModifiedDate

Reference: MFSQL Connector Operations

Conflict resolution

When the same object changes in both M-Files and SQL between synchronisation runs, the connector has to decide which version wins. An analysis of the current behaviour identified areas that need further work before we can describe conflict handling as complete and predictable.

Areas under review:

  • Making the winning-version rule explicit and consistent across the update procedures, rather than implied by processing order.

  • Detecting a genuine two-sided change rather than treating any difference as a one-way update.

  • Surfacing conflicts in the process log so they can be found after the fact, instead of resolving silently.

  • Finer-grained precedence. Today the winning side is set per class, so a change in M-Files and an unrelated change in SQL to two different properties of the same object are resolved as one contest. Property-level precedence would let each side keep what only it changed.

No target release yet. If conflict behaviour matters in your environment, tell us how you expect it to resolve — that shapes the design.

M-Files Configurations

Goal: move configuration from SQL settings tables into M-Files Configurations, with VAF brokering secure connections to SQL. Initially optional; becomes the default once broadly adopted.

Configuration sources

  • Current in Configurations (baseline): Web API connection, ODBC connection.

  • Move from SQL to Configurations:

    • MFSQL user selection (update MFVaultSettings)

    • MFSettings defaults and updates

    • Vault content package install/setup

  • Other objects/settings to manage via Configurations:

    • Class selection and class settings (update MFClass)

    • Property list sync and custom column options (update MFClass/MFClassProperty)

    • Context menu setup (update MFContextMenu)

Operational status and automation

  • Dashboarding: errors, ProcessBatch statistics, usage overview.

  • Automate SQL procedures and views:

    • Curated class update procedures

    • Reporting/analysis views

    • Use VAF to trigger automatic metadata structure updates in SQL

Reporting and observability

Make reporting easier to use and surface in M‑Files where appropriate.

  • Error log, process log, VAF log aggregation and drill-down

  • Process performance metrics and trends

    • Class, column, table, database, and overall stats

  • User and group usage stats

Payload and performance changes

  • JSON payloads instead of XML to remove limits and improve throughput

  • Reduce end-to-end processing time and metadata sync impact on transactions

  • Continuous metadata sync without full-object scans; auto-update object change history

  • A structured performance analysis across the main synchronisation paths, so improvement work is driven by measurement rather than by where problems happen to get reported

Installation and setup streamlining

  • Install and configure the Vault App (VAF)

  • Install Web Service on web server (if used)

  • Ensure M‑Files connectivity from SQL host where required

  • Validate SQL Server connectivity and prerequisites

  • Execute SQL installation

  • Validate SQL→MF connection and basic operations

Installer signing

Installing the current package raises a Windows SmartScreen warning (“Windows protected your PC”) because the installer is not signed by a certificate Windows already trusts. That warning is not a sign of a problem with the package, but it is a poor first impression and it makes the install harder to get through a change-control process.

We are moving to a signed installer. The constraint is procurement and reputation lead time with the certificate authority rather than the work of signing itself, so this is being progressed independently of any single release.

Packaging approach

We are also reviewing how the product is packaged. The connector installs a well-defined set of SQL objects, assemblies, and a vault application — a narrower job than the general-purpose installer technology currently used to deliver it. A lighter, scripted installer would let us make the install more transparent about what it is doing and easier to run in environments where an interactive MSI is awkward, such as an unattended or change-controlled deployment.

This is under evaluation, with no committed direction yet. Whatever we do here has to keep the upgrade path intact for existing installations.

Running without an M‑Files installation on the SQL Server

Today the MFSQL Connector expects M‑Files to be installed on the SQL Server itself, because it loads the M‑Files interop assembly from that installation. Some organizations would rather not place M‑Files on a database server at all, whether for security separation, patching policy, or licensing.

We are investigating supporting installations where the SQL Server has no M‑Files installation on it. This is investigation rather than a commitment: the change reaches into how the connector locates and keeps the interop assembly current, so the supported approach has to be settled before a release can carry it.

Worth understanding how this relates to 5.13.38.82. That release made the connector find the interop assembly through the local M‑Files installation and reload it automatically when M‑Files is upgraded, which removed a long-standing manual step. That mechanism depends on M‑Files being present locally, so a client-less SQL Server needs a different answer for both locating the assembly and keeping it current. Solving it well means keeping the automatic behavior customers gain in 5.13.38.82 rather than trading it away.

No target release yet. If this scenario matters to your environment, tell us: knowing who needs it and why helps us prioritize it and design for real deployments.

Platform changes we are tracking

Some future work is driven by M-Files rather than by us. We track these so the connector changes ahead of the platform, not behind it.

  • Replacement of VBScript in M-Files. M-Files is developing new scripting methods intended to replace VBScript. Parts of the connector’s vault-side behaviour rely on the current scripting model, so the replacement will reach the connector once M-Files announces it. We are following the change and will publish guidance when the timeline is known.

Commercial and licensing

  • Evolve pricing to be more usage-focused.

  • Better visibility of licence status — a clear view of licence state per module, and earlier, more prominent warnings ahead of expiry, surfaced where someone will actually see them rather than in a log entry or a single email.

  • Review of how licence expiry is handled. The current behaviour and any change to it are under review; nothing here changes in a release without advance notice.