Release notes - version 2.0

SQL Source Control is an add-in for SQL Server Management Studio that allows you to source control your databases.

Note that SQL Source Control is not a source control system; it allows you to store your databases in your existing source control system.

This article discusses:

Features in version 2.0
Known issues in version 2.0
Bug reports and feedback
Getting more information

Features in version 2.0

Version 2.0 of SQL Source Control includes the following new features:

The ability to source control static data
SQL Source Control lets you source control your static (lookup/reference) data. Static data is the non-transactional data an application may depend on. Typically, it does not change frequently; an example would be a table of US states.

To source control data, first link it to source control, then commit it.

Note that you are recommended only to source control static data. Source controlling large quantities of data or transactional data can result in poor performance.

For more information, see Source controlling data
The evaluation repository
If you do not have a source control system set up, or do not want to use your existing system to evaluate SQL Source Control, you can create a Subversion repository using the Just Evaluating option when you link a database to source control.

For more information, see Using the evaluation repository
Better support for the shared development model
SQL Source Control supports both a dedicated and a shared database development model.

When you link a database to source control, you must specify whether the database will be shared or dedicated. This allows SQL Source Control to better support your development model. For example, under a shared model, SQL Source Control displays information about which SQL Server user made which change. This means you can avoid committing another user's changes, and more easily see who is working on what.

Known issues in version 2.0

SQL Source Control version 2.0 has the following known issues:

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.

We aim to address this issue in the forthcoming version 2.1

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

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

Bug reports and feedback

We are continuing to develop SQL Source Control, and we value any feedback you may have.

Please let us know about any issues you may encounter.

If SQL Source Control encounters a serious issue, you may see an error report dialog box:

Please click Send Error Report, and - if possible - provide detailed feedback, as these reports are extremely valuable to us.

These error reports may include:

a stack trace
your SQL Server and operating system version
the Windows user you are logged in as, and your domain
This is so we can identify recurrent bugs.
information from the SQL Source Control logs
In some conditions, this may include information about your database schema.

Getting more information

Was this article helpful?

Search support