Commit with Migration Script Creates 2 Changesets

uchimoto

When attempting to commit changes with a Migration Script to cover all the changes, SSC creates 2 changesets in TFS instead of just 1. The first changeset contains the object that were modified and the second changeset has just the migration script.

Subsequently when using SSC to Get Latest on another instance of the same database (that isn't at latest version), the object level changes checked in are displayed but not the Migration Script that covers the changes. This leads to having to run the Migration Script manually.

I've had this happen twice today. Steps I'm taking when it happens:
1. Make changes to db objects.
2. In SSC Commit Changes click add Migration Script link.
3. Select all changes when asked which changes the Migration Script should cover.
4. Edit the Migration Script and click Proceed to Commit
5. Select Save on prompt.
6. See that migration script is listed now above all the changes in Commit Changes screen.
7. Add comment and click Commit.
8. BOOM... 2 changesets.

Using SSC 3, SQL Server 2008 R2, TFS 2010.

Chris Auckland

Thanks for your post.

I think this is the expected behaviour unless I'm misunderstanding. The database scripts and the migration scripts are linked to different locations in the TFS project, so you'll get a changeset for each.

I'm not sure why the migration script isn't being picked up when you 'get latest'. Is the seconds database linked to the same scripts and migrations folder in TFS?

uchimoto

You are correct. I went back and looked at the project history. I never noticed that it was creating 2 changesets for each commit with a migration script.

The migration scripts are not getting picked up, though, when we do get latest. This has just started happening. The databases all share the same scripts and migrations folder in TFS.

Thanks

uchimoto

Here's an update on the migration scripts. I made some changes to the database this weekend. I started in my development copy. These changes were very minor - added 2 columns to end of an existing table - and so they were not committed with a migration script. When it came to to update the second database, rather than seeing the changes (2 new columns), the Get Latest screen presented the last 2 migration scripts that where checked in, even though those changes had already been applied to the second database.

This would appear to be a bug in SSC.

Chris Auckland

Did you commit the minor changes before you attempted the 'get latest' on the second database?

Also, could you check the database level extended properties of the second database and make sure the revision is later than both the migration scripts? It's this value that SQL Source Control checks to see if a migration script should be applied.

uchimoto

Yes. The minor changes were committed before I attempted the "Get Latest".

We have 7 copies of the same database (production, build, developers). They are all set up in SSC as Dedicated and they all point to the same TFS projects for database and migration scripts. These 7 database should all be at the same version right now. However, I see 3 different values for SQLSourceControl Database Revision under the Extended Properties.

Thanks