Knowledge base

Error: Failed to resolve no-ops after 5 tries

Date: 02/09/2011
Product: SQL Source Control

In some circumstances you may encounter the error message "Failed to resolve no-ops after 5 tries" on the Commit Changes or Get Latest tab. This occurs when one of several possible issues prevents SQL Source Control from determining the correct list of objects with changes to commit or get.

This issue is logged in our bug-tracking system with the reference number: SOC-2670

Causes of the error

This can affect users in three situations:

• If you are using the Vault source control system's Sharing feature

  Using the Vault Share command for databases can cause problems for the current version of SQL Source Control, leading to a situation where it is unable to determine the list of objects with changes.

  To resolve this issue, you are recommended to disable sharing in Vault, then unlink and relink the database to source control.

  If the problem persists, steps to manually resolve this issue are described 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 you or a member of your team commits or gets a change and does not include all objects with dependencies, the database in source control can be left in an invalid state.

  To avoid this issue you are recommended always to include all objects with dependencies when you commit or get changes.

  Steps to manually resolve this issue are described below.

• When SQL Source Control encounters known issue SOC-2670

  In order 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, leaving SQL Source Control unable to determine changes.

  This can occur in some circumstances when you unlink and relink a database, or when two people are modifying the same objects.

  To resolve this issue, you must manually update one of these local copies. Steps to do this are described below.

This article describes a general workaround for the issue. The workaround suggested in this article may not be appropriate for all users. If the workaround does not work for you, you should contact Red Gate if you encounter the issue. Information you provide helps us address any underlying bugs and improve SQL Source Control in future versions, as well as diagnosing and helping you solve your specific problem.

Manually resolving the error

The most common underlying cause of this issue 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 it is used to help determine which changes are uncommitted. If an object is missing from the working base, or at an unexpected version, SQL Source Control cannot correctly determine which objects have changed.

To resolve the error, you must use your source control system to manually update the SQL Source Control Working Base to the latest source control version (Head).

Alternatively, you can update the working base to a specific version you know to be stable.

To find the file path to the Working Base, on the Setup tab of SQL Source Control, where it says Linked to, Shift + right-click, and select Open Working Base Location:

The Working Base folder opens in a new Explorer window.

Note that 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. For this reason, you arr generally recommended not to modify your Working Base, as it is possible to 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 has also changed:

• The Commit Changes tab shows the differences between the current database version and the updated Working Base. But your current database version is less recent than the current source control version. So 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.

The simplest way to resolve these issues is to commit all the changes you have made and want to keep, and then undo all other changes. This commits your changes and updates your database to the latest source control version. Additionally, it synchronizes the local copies of the database schema, restoring the normal operation of SQL Source Control.