SQL Source Control 5

This error is shown on the Commit or Get latest tab when SQL Source Control can't determine the correct list of objects with changes. The error is logged in Redgate's bug-tracking system with the reference number SOC-2670.

Causes

If you're using the Vault Share command

Linking to a folder shared with the Vault Share command causes problems with SQL Source Control. You won't be able to commit or get changes.

To fix this, unlink the database, then link to the original Vault folder, not the shared copy. Committing changes to the original folder will automatically update the shared folder. If this doesn't work, steps to fix the error manually are described under Fix below.

When dependency issues leave the source control version of the database in an invalid state

SQL Source Control detects dependencies when you get or commit a set of objects. If someone commits or gets a change and doesn't include all its dependencies, the database in source control may be left in an invalid state. For example, you may have committed a view that selects from a table, but not committed the table it selects from.

When SQL Source Control encounters known issue SOC-2670

To determine which database objects have changes to commit or get, SQL Source Control maintains local copies of the objects creation scripts. These copies can get out of sync.

This may happen when you unlink and relink a database, or when two people are modifying the same objects.

Fix

The most common cause is that one of the local scripts folders, the working base, is incomplete. The working base is a representation of the database before you made your current changes, and is used to determine which changes are uncommitted. If an object is missing from the working base, or at an unexpected version, SQL Source Control can't determine which objects have changed.

For more information about the working base, see How SQL Source Control works behind the scenes.

To fix the error, use your source control system to manually update the working base to the latest source control version (head). Alternatively, you can update the working base to a specific stable version.

To find the working base file path, on the Setup tab, expand the Under the hood section and click Open working base folder:

The working base folder opens in a new Explorer window.

Because the working base is used to detect uncommitted changes, modifying it affects which objects are displayed on the Commit changes, Get latest, and Undo tabs. We don't recommend you modify the working base unless advised by Redgate support, as you might lose or overwrite your work.

After updating the working base

Because the working base has changed, the list of objects with changes to commit, get, and undo also changes.

The Commit changes tab shows the differences between the current database version and the updated working base. However, because your current database version is less recent than the current source control version, committing a change overwrites the current source control version of an object with the older version from your database.
The Get latest tab shows no changes to get, even if there are changes. This is because SQL Source Control now considers the database to be at the latest version.
The Undo changes dialog box shows the differences between the current database version and the updated working base. This means the working base version is more recent than the database version, so undoing a change updates an object to the latest source control version. Undo has become equivalent to Get latest.

To fix these issues, commit all the changes you've made and want to keep, then undo all other changes. This commits your changes and updates your database to the latest source control version, and synchronizes the local copies of the database schema, restoring normal SQL Source Control operation.