Resolve conflicts

dbForge Source Control helps to resolve conflicts as a result of discrepancies between the latest version of an object/data in version control and in your local database. The most common reason for conflicts is when several people simultaneously make different changes on the same objects/data.

To start working with Source Control Manager, first, you need to link a database to the version control repository. To do that, follow the steps in the how-to topics depending on the source control or version control systems you use:

The linked database gets the following icon in Object Explorer:

Source Control label

After the database has been linked to the remote repository, dbForge Source Control checks whether any changes were made to the database locally or remotely and committed to the repository. In addition, the tool checks if there are any conflicts meaning that several developers were making changes to the same file both in the repository and in the database.

The Refresh progress window opens automatically, showing the stages of the refresh operation.


After the refresh operation is complete, Source Control Manager opens displaying all the changes in the following sections:

It should be noted that Source Control Manager can display either all three sections or two of them or just one section.

The tool distributes the changes in the following sections

If the database and version control repository are identical and no changes are found, the following window is displayed:

The database and version control repository are identical

To resolve a conflict

In the Conflicts section, select the checkboxes next to the conflicts that you want to resolve.


If you select the checkbox next to Conflict, all conflicts will be selected.

The Conflict window

As you can see in the screenshot above, the Source Control grid contains the following columns:

Column Description
Change Type Actions to be applied to the object or static data; in this case, the single available change type is Conflict
Type The type of the object
Name The name of the object that will undergo changes; a <name> (Data) construction refers to static data
Owner The schema or database in which the object was created

Select the required way to resolve your conflict:

  • Get Local: Your version of the object/data will be committed to source control.
  • Get Remote: Your changes will be discarded. The local database will be updated with the latest version of the object/data from source control.

When you click Get Local, the changes are then displayed in the Local changes section of Source Control Manager.

When you click Get Remote, the changes are then displayed in the Remote changes section of Source Control Manager.

After that, you can work with the changes from the Local changes section, as described in Commit changes, and with the changes from the Remote changes section, as described in Get the latest version.

Conflicts with static data

Keep in mind that data changes may not apply without the related schema changes. If you have applied both schema and data changes to a database object, you need to commit them simultaneously. Similarly, if you are pulling someone else’s schema and data changes, pull them simultaneously.

Therefore, if you have a schema conflict and a data change on an object, the change cannot be committed or retrieved without resolving the schema conflict beforehand.