1. Deployments and vault changes

This guide covers the safe movement of a Connector-based solution between environments (DEV → QA → Production) and what to do when the target vault changes.

1.1. Key scenarios

  • Moving from one environment to another while preserving aliases and IDs.

  • Pointing an existing SQL database at a different vault.

  • Refreshing metadata without losing user-defined columns in class tables.

1.2. New vault (greenfield) deployments

Best practice is to create a new database, install the Connector from the installer package, and then script any custom procedures from the previous database into the new database if required.

Just repointing an existing database to a different vault is possible, but requires careful planning and consideration of all metadata-related tables, views, and custom procedures.

1.3. Environments created as a structure copy of DEV

When QA or Production is created as a structure copy of DEV, all M‑Files object references typically remain the same. In this scenario:

1.3.1. Update settings

Update the values in the settings table to point to the new vault.

1.3.2. Synchronize metadata

Use the procedure spMFDropAndUpdateMetadata to synchronize metadata after the vault was changed in the settings table. This procedure will retain all the user-defined columns in the Connector tables.

1.4. Scripting and deployment tooling

In larger solutions with many custom procedures and functions, use a scripting tool to manage deployments consistently. The DBDeployTool is available on request to assist with this task.

1.5. Notes and tips

  • Several class tables include custom data. A metadata refresh maintains these user-defined columns; it does not overwrite them.

  • Always validate on QA using a representative dataset before moving to Production.

  • Keep a rollback plan: a recent database backup plus a simple way to restore the previous MFSettings values.