Would love to see a feature that ignores any local changes and allows you to simply bring the local database up to the latest version
We often restore databases into our working folder and would love an option to simply bring that database up to the latest source controlled version. Right now when we restore a database Source Control thinks we made a bunch of changes so we end up having to "undo" those changes.
Debbie Murray
shared this idea
-
Jeff Shepler
commented
How about using sql compare before the restore, generate change script, do the restore, run the script.
-
Debbie Murray
commented
@James No, we restore customer data to setup up certain data situations for testing purposes. The customer's database is a version (or several) behind, hence the disconnect. We would like to restore that data and then simply bring that database up to the most recent source controlled version.
-
AdminJames Billings
(Admin, Redgate)
commented
What Tim was suggesting is using Get Latest instead of the restore, which would update your dev databases to whatever is currently in the source control repository.
Are you restoring from a backup because that's more recent than what's in the repository?The reason that you see the objects on the commit tab is because the restore has made changes to the database which haven't also been made to the "working base" scripts folder. We see differences in these as changes you need to commit (see http://documentation.red-gate.com/display/SOC3/How+SQL+Source+Control+works+behind+the+scenes for more information on this). Doing a Get Latest from the repo will update the WB and Database together, so you won't see spurious differences on the commit tab.
-
Debbie Murray
commented
@Tim - because the database differences that result from the restoring a database to a previous version show up as changes to check in. No changes show on the Get Latest tab after restoring a database (which is older than the most current in source control).
-
Tim
commented
How is this different than doing a Get Latest?