Commit with Migration Script Creates 2 Changesets

A SQL Server Management Studio add-in to source control your database in Subversion or Team Foundation Server.

Moderators: Chris Auckland, David Atkinson, sherr, PhilScrace, andy.campbell.smith

Commit with Migration Script Creates 2 Changesets

Postby uchimoto » Fri Oct 26, 2012 10:09 pm

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.
uchimoto
 
Posts: 4
Joined: Fri Oct 26, 2012 9:53 pm
Location: Boulder, CO

Postby Chris Auckland » Tue Oct 30, 2012 3:52 pm

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?
Chris
Chris Auckland
 
Posts: 757
Joined: Tue Oct 24, 2006 2:12 pm
Location: Red Gate Software Ltd.

Postby uchimoto » Tue Oct 30, 2012 11:55 pm

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
 
Posts: 4
Joined: Fri Oct 26, 2012 9:53 pm
Location: Boulder, CO

Postby uchimoto » Mon Nov 05, 2012 7:14 pm

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.
uchimoto
 
Posts: 4
Joined: Fri Oct 26, 2012 9:53 pm
Location: Boulder, CO

Postby Chris Auckland » Mon Nov 05, 2012 7:18 pm

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.
Chris
Chris Auckland
 
Posts: 757
Joined: Tue Oct 24, 2006 2:12 pm
Location: Red Gate Software Ltd.

Postby uchimoto » Thu Nov 08, 2012 11:51 pm

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
uchimoto
 
Posts: 4
Joined: Fri Oct 26, 2012 9:53 pm
Location: Boulder, CO


Return to SQL Source Control 3

Who is online

Users browsing this forum: No registered users and 1 guest