How to resolve conflicts

A conflict arises when there’s a discrepancy between the latest version of an object in source control and the one in the local database. The most common reason for conflicts is that multiple people modified the same file simultaneously. dbForge Source Control helps resolve conflicts in the Source Control Manager.

The guide provides the following instructions:

Before you can use the Source Control Manager, you must link a database to the version control repository by following the steps outlined in the relevant how-to topic:

The linked database gets the following icon in Database Explorer:

Source Control label

The Source Control tool checks if any changes were made to the database, locally or remotely, and if these changes were committed to the repository. In the same way, it checks whether any changes were committed to the version control and whether these changes were deployed to the linked database.

In addition, the tool scans for conflicts that can occur when multiple developers make changes to the same file in the repository and in the local database.

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

Refresh

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

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

The tool distributes the changes in the following sections

Note

Local changes section

  • The Add change type indicates that the object was created locally in the database that is version-controlled using Source Control, and has not been committed to the remote repository yet. Selecting the object and clicking Undo will remove it from the local database.
  • The Remove change type means that the object was deleted from the local database that is version-controlled using Source Control, but is still present in the remote repository. Selecting the object and clicking Undo will restore it in the local database.
  • The Modify change type signifies that changes were made to the object in the local database that is version-controlled using Source Control. As a result, the object’s DDL in the local database differs from the version stored in the remote repository. Selecting the object and clicking Undo will discard the changes made to the object in the local database, reverting it to the version from the repository.

Remote changes section

  • The Add change type indicates that the object has been added to the remote repository since the last synchronization, and is not present in the local database that is linked to this repository via Source Control. Clicking Get Latest will add the object to the local database.
  • The Remove change type means that the object has been removed from the remote repository since the last synchronization but is present in the local database that is linked to this repository via Source Control. Clicking Get Latest will remove the object from the local database.
  • The Modify change type indicates that the object has been modified in the remote repository since the last synchronization. As a result, the object’s DDL in the repository differs from the version stored in the local database that is linked to this repository via Source Control. Clicking Get Latest will update the object in the local database to match the version from the repository.

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 you want to resolve.

Note

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

The Conflict window

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 Type of the object
Name Name of the object that will undergo changes. A <name> (Data) construction refers to static data
Owner 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. The changes are then displayed in the Local changes section of the Source Control Manager and can be managed as described in Commit changes.
  • Get Remote: Your changes will be discarded. The local database will be updated with the latest version of the object/data from source control. The changes are then displayed in the Remote changes section of the Source Control Manager and can be managed 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 schema and data changes to a database object, it is important to commit them together. Similarly, if you pull schema and data changes made by someone else, retrieve them simultaneously.

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

Let us demonstrate the conflicts and their resolution on an example.

Worked example: How to resolve a conflict

Let us showcase how to resolve conflicts using the Source Control tool available in dbForge Studio for SQL Server.

Suppose two sample databases - BikeStoresDev1 and BikeStoresDev2 contain the same tables.

1. Link both databases to the same version control repository - development. After that, the Source Control Manager opens for each database, displaying the local changes, if any, or showing that the databases are identical.

2. The first developer (Dev1) modifies the production.brands table:

USE BikeStoresDev1
GO

IF DB_NAME() <> N'BikeStoresDev1' SET NOEXEC ON
GO
ALTER TABLE production.brands
ADD brand_description varchar(500);
GO
SET NOEXEC OFF
GO

3. The second developer (Dev2) make the changes to the production.brands table and commits them to the repository:

USE BikeStoresDev2
GO

IF DB_NAME() <> N'BikeStoresDev2' SET NOEXEC ON
GO
ALTER TABLE production.brands
ADD brand_description varchar(50);
GO
SET NOEXEC OFF
GO

4. Dev1 modifies the production.categories table as follows:

USE BikeStoresDev1
GO

IF DB_NAME() <> N'BikeStoresDev1' SET NOEXEC ON
GO

ALTER TABLE production.categories
ALTER COLUMN category_name varchar(255) NULL;
GO

SET NOEXEC OFF
GO

5. Dev2 modifies the same table - production.categories - and commits these changes to the repository:

USE BikeStoresDev2
GO

IF DB_NAME() <> N'BikeStoresDev2' SET NOEXEC ON
GO

ALTER TABLE production.categories
ALTER COLUMN category_name nvarchar(255) NOT NULL;
GO

SET NOEXEC OFF
GO

5. Dev1 modifies the sales.customers table as follows:

USE BikeStoresDev1
GO

IF DB_NAME() <> N'BikeStoresDev1' SET NOEXEC ON
GO
ALTER TABLE sales.customers
  ADD skype varchar(50) NULL
GO

6. Dev2 modifies the sales.orders table and deletes the sales.customers table. Then, commits these changes to the repository:

USE BikeStoresDev2
GO

IF DB_NAME() <> N'BikeStoresDev2' SET NOEXEC ON
GO
ALTER TABLE sales.orders
  DROP CONSTRAINT FK_orders_customers
GO
ALTER TABLE sales.customers
  ADD skype varchar(60) NULL
GO

7. Dev1 refreshes the Source Control Manager of the BikeStoresDev1 database. Source Control detects the changes and displays them with the Conflict change type in the Conflicts section:

Conflict

8. Dev1 decides that changes in the sales.customers and sales.orders tables have been mistaken. So, Dev1 wants to commit their local changes for these tables and override the changes made by Dev2. To do this, select the sales.customers and sales.orders tables and click Get Local.

The tables are then displayed with the Modify change type in the Local changes section.

In addition, Dev1 wants to get remote changes made to the production.categories and production.brands tables by Dev2. To do this, select the production.categories and production.brands and click Get Remote.

In the Local changes section, select the object, write the comment, and click Commit to commit the changes to the repository, or click Undo to discard the changes made to the object in the production database, reverting it to the version from the repository. The Commit progress window opens and shows the stages of the commit operation. When all the stages are complete, click OK to close the window.

In addition, Dev1 wants to get remote changes made to the production.categories and production.brands tables by Dev2. To do this, select the production.categories and production.brands and click Get Remote.

2. Change the development database as follows:

  • Remove the orders table.
  • Add a column to the customers table.
  • Add a column to the products table.

3. Refresh the Source Control Manager of the development database, select these changes, and click Commit to commit them to the development repository.

4. Change the production database by adding columns per table.

5. Refresh the Source Control Manager of the production database. Source Control detects the changes and displays them with the Conflict change type in the Conflicts section:

The Conflict window

6. Select the customers table and click Get Local. The table is then displayed with the Modify change type in the Local changes section.

In the Local changes section, select the object, write the comment, and click Commit to commit the changes to the repository, or click Undo to discard the changes made to the object in the production database, reverting it to the version from the repository. The Commit progress window opens and shows the stages of the commit operation. When all the stages are complete, click OK to close the window.

Get local and Get remote

7. In the Conflicts section, select the orders and products tables and click Get Remote.

Get local and Get remote

The orders table is then displayed with the Remove change type and the products table with the Modify change type in the Remote changes section. Select the tables and click Get Latest to update the object in the production database to match the version from the repository. The Get Latest progress window opens, showing the stages of the operation. When all the stages are complete, click OK to close the progress window.

Get Latest

10. Refresh the Source Control Manager for the production database. To close the Refresh progress window, click OK to close the window.

The Source Control Manager shows no changes in the objects in the production database.

Identical databases

11. Switch to the Source Control Manager of the development database and refresh it. Source Control detects the changes and displays the customers table with the Modify change type in the Remote changes section. Select the table and click Get Latest to update the object in the development database to match the version from the repository.

Update the development database with the changes

After the refresh operation, the Source Control Manager will show no changes and determine databases as identical.

Want to Find out More?

Overview

Overview

Take a quick tour to learn all about the key benefits delivered by dbForge Studio for SQL Server.
All Features

All features

Get acquainted with the rich features and capabilities of the Studio in less than 5 minutes.
Request a demo

Request a demo

If you consider employing the Studio for your business, request a demo to see it in action.
Ready to start using dbForge Studio for SQL Server?
Download a free 30-day trial