SQL Source Control Metadata should be ignored

Compares and synchronizes SQL Server databases, backups and scripts.

Moderators: JonathanWatts, Chris Auckland, David Atkinson, eddie davis, Anu Deshpande, Michelle Taylor, alice.easey, james.billings, chengvoon.tong

SQL Source Control Metadata should be ignored

Postby Alex Fekken » Fri Jan 20, 2012 2:36 am

When I compare two databases that are separately under SQL Source Code control, the diff script contains a statement block starting with:

/*
Start of RedGate SQL Source Control versioning database-level extended properties.
*/

Especially when the databases are under source control in separate repositories, but also when databases themselves are compared (rather than any revisions), this information should be ignored.

At the very least there should be a separate option to ignore this metadata (on by default) while allowing other extended properties (e.g. ms_description) to be synced.
Alex Fekken
 
Posts: 20
Joined: Tue Nov 22, 2005 11:20 pm

Postby David Atkinson » Fri Jan 20, 2012 12:12 pm

Alex,

Thanks for the feedback.

If you don't sync this meta data, then if you try to sync to the database in future from source control, then as it wouldn't know what version the target was, it might not pick up the correct migration scripts.

Is there any reason why it's important for you _not_ to update the version extended property on the target database?

David Atkinson
Red Gate
David Atkinson
 
Posts: 1124
Joined: Mon Dec 05, 2005 4:54 pm
Location: Twitter: @dtabase

Postby Alex Fekken » Sun Jan 22, 2012 2:51 am

Hi David,

Thanks for your quick response.

We are not using migration scripts (yet), I can see how that may change our processes.

But for now the databases are separately under source control, i.e. against different repositories. This is because they are deliberately kept at different release levels: usually (our copy of) production versus UAT versus development. We periodically use SQL Compare to migrate (some or all of the) changes across from dev to UAT and/or UAT to production (and sometimes in reverse direction to revert changes) without wanting to change the repository against which each database is linked. I.e. we want the changes to be applied as if they were done manually through a release or hotfix script.

In fact we use SQL Compare to generate the update scripts for the client's production environment as well. But because the client typically does not source control their databases and frequently scrutinizes the update scripts that we send them, we do not want the source control metadata included in them.

Alex
Alex Fekken
 
Posts: 20
Joined: Tue Nov 22, 2005 11:20 pm

Postby David Atkinson » Mon Jan 23, 2012 11:12 am

If you edit your project and visit Options, there is an option called "Ignore Migration Scripts for Database". This setting can be saved with the project, or you can use the "My Defaults" feature to ensure that each time you create a new project the checkbox is selected.

Do let us know if this solves your problem.

Kind regards,

David
David Atkinson
 
Posts: 1124
Joined: Mon Dec 05, 2005 4:54 pm
Location: Twitter: @dtabase

Postby Alex Fekken » Tue Jan 24, 2012 2:20 am

Thanks David, yes that solves my problem.

It wasn't obvious to me (and perhaps others) that "Ignore migration scripts..." also controls revision metadata.

Kind Regards,
Alex
Alex Fekken
 
Posts: 20
Joined: Tue Nov 22, 2005 11:20 pm


Return to SQL Compare 10

Who is online

Users browsing this forum: No registered users and 0 guests