SQL Source Control 4

SQL Source Control 2.1 release notes

March 30th, 2011

New features

Version 2.1 of SQL Source Control introduces support for any source control system with a command line interface.

Presets are included for:

  • Bazaar
  • CVS
  • Git
  • Mercurial
  • Perforce

Additionally, you can configure SQL Source Control to work with other source control systems.

For more information, see Working with config files.

Known issues

For GIT and Perforce, committing changes with SQL Source Control commits all changes, not only database changes

If you are using GIT or Perforce, committing changes with SQL Source Control can commit all currently uncommitted changes for the working folder you are linked to.

This means that, for example, you could accidentally commit application code changes as well as database changes from within SQL Source Control.

To avoid this issue, we recommend you create a new, empty folder in source control to link your database. This makes sure the folder contains only database code, and you cannot commit non-database changes.

Issues for Vault users upgrading from the early access version

Users upgrading to version 2.1 from previous early access version may encounter issues.

If you are upgrading from an early access version, you are recommended to first do the following:

  1. Unlink your databases from source control.
  2. In Windows Explorer, naviagte to: %localappdata%\Red Gate\SQL Source Control <version number>
  3. Delete the files LinkedDatabases.xml, and TableDataConfigs.xml

Link your databases to source control again.

Spurious object change notification in rare circumstances

In some situations, it is possible to see a blue change notification in the Object Explorer, where there is no corresponding object with changes to commit on the Commit Changes tab.

This can occur, for example, if you alter a stored procedure and run it, then remove the change you made and run it again. The Object Explorer would continue to show a change, but there would be no change listed on the Commit Changes tab. Once you have visited the Commit Changes tab, and SQL Source Control has accurately determined the differences, the blue indicator is removed from the Object Explorer.

This is because the change detection performed on the Commit Changes tab is more detailed, and considers the state of the database, whereas the change notifications in the Object Explorer are displayed when a change is made.

Generally, you are unlikely to encounter this issue. However, it may be slightly more common when working under a shared development model.

For example:

  • If two users are working on the same database under a shared model, when the first user makes a change, both users see a blue change notification in the Object Explorer. When the first user commits their change, the notification disappears for that user, but continues to be displayed for the second user. For the second user, there is no corresponding change on the Commit Changes tab.

When the second user goes to or refreshes the Commit Changes tab, the spurious notification is removed from the Object Explorer.

Unlinking if you downgrade to version 1

If you uninstall SQL Source Control version 2, and install version 1, any databases that were linked to source control while you were using version 2 are unlinked. Simply re-link them to continue using them with SQL Source Control.

Performance issues when source controlling large quantities of data

If the data tables you are source controlling have a large number of rows, the Commit Changes and Get Latest tabs may be slow to populate and refresh.

Because performance can be poor for large quantities of source controlled data, we recommended you only source-control static (lookup) data.

Large quantities of data, or data that changes frequently (such as transactional data) should not be source-controlled.

Didn't find what you were looking for?