Resolve conflicts

A conflict occurs when the version of a database object in the local database differs from the version in the source control repository. This often happens when multiple users modify the same object at the same time. You can resolve conflicts using Source Control Manager in dbForge Studio for SQL Server.

Resolve conflicts with objects

1. In the Conflicts section, select the checkboxes next to the items you want to resolve.

Tip

To select all items, select the checkbox next to Conflicts.

2. Choose how to resolve each conflict:

• Get Local – Keeps your local changes and moves the item to the Local changes section. You can then commit it to the repository.
• Get Remote – Discards your local changes and updates the object with the latest version from the repository. The item appears in the Remote changes section.

Resolve conflicts with static data

To maintain data integrity, commit schema and static data changes together. If you modify both a database object structure and its static data, include both in a single commit.

Likewise, when applying updates from the repository, retrieve both schema and static data changes at the same time.

Note

If a schema conflict exists alongside a static data change, you must resolve the schema conflict before you can commit or retrieve the related data.

Walkthrough: Resolve conflicts between two developers

This walkthrough shows how to resolve conflicts between changes made by two developers (Dev1 and Dev2) to the same database objects.

Step 1: Link databases

1. Link both BikeStoresDev1 and BikeStoresDev2 databases to the same repository, for example, development.

Source Control Manager will open for each, showing current local changes.

Step 2: Modify objects

1. 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

2. Dev2 modifies the same table and commits changes:

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

3. Dev1 modifies the production.categories table:

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

4. Dev2 modifies the same table and commits changes:

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:

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 and sales.customers tables and commits these changes:

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

Step 3: Detect conflicts

Dev1 refreshes the Source Control Manager of the BikeStoresDev1 database. Conflicts are detected in:

• Conflicts – production.brands, production.categories, and sales.customers
• Remote changes – sales.orders

Note

The sales.orders table appears as a remote change due to its dependency on the sales.customers table.

Step 4: Resolve conflicts

Dev1 chooses to:

• Keep local changes for the sales.customers table.
• Get remote changes for the production.categories and production.brands tables.

Commit local changes

1. In the Conflicts section, select the checkbox next to the sales.customers table, then click Get Local.

The sales.customers table moves to the Local changes section with the Modify change type.

2. In the Local changes section, select the item, enter a commit comment, then click Commit.

The Commit progress window opens, followed by the Refresh progress window, which updates Source Control Manager of the BikeStoresDev1 database.

Get remote changes

1. In the Conflicts section, select the checkboxes next to the production.categories and production.brands tables and click Get Remote.

2. The items move to the Remote changes section. Select them and click Get Latest to update the local database.

Note

To revert the conflict resolution and recheck changes, click Refresh.

For instructions on committing changes to a repository, see Commit changes.