Treat renames as renames instead of a drop and an add
When renaming (tables in this instance) the commit changes dialogue says that there are drops and creations - this will possibly confuse rollbacks etc
Is it possible for the interface to "understand" renames?
SQL Source Control 3.0 is now available!
It includes a new feature called ‘Migrations’ that will help avoid data loss when renaming a table as it allows you to create, store and share SQL migration scripts for accurate deployment.
For more information about Migrations, please visit:
Benny Bech commented
Migration scripts only solves the DB side of the problem, the Versioncontrol loses history during this. There is NO connection between the old name and the new name in the history (i'm using SVN but the problem must be the same for all Version Control systems).
The problem is even bigger on stored procs (no need for migration script).
I've tried renename the stored procs SQL script name in SVN, but the SourceControl (3.0) dosn't detect any changes (propoply because the name ISN't changed in the script)
An Early Access build of SQL Source Control 3.0 is available which includes a new feature called "SQL Migrations".
This feature will help avoid data loss when renaming a table as it allows you to create, store and share SQL migration scripts for accurate deployment.
So when a table rename is identified as a table drop and create by SQL Source Control, you can override this behaviour by creating a bespoke script to cover these changes (using sp_rename to avoid any data loss). Your bespoke script will then be used by other developers when they invoke 'Get Latest' in SQL Source Control and will also be used during deployment via SQL Compare.
The installer zip can be found here:
As I said, this is an Early Acces build - so does not include all the functionality we are hoping to provide with "SQL Migrations". We'd love to hear feedback from you regarding whether this feature provides a good solution to the problem you've described.
Why can't Red-Gate detect that the newly named table has the same object ID as the one that was deleted and create their own script to migrate the data?
I created a test table and then renamed it. The Object ID remains the same...! So if they find that the new table ID exists in the old version, wahla, it has been renamed...
Sean WOW commented
I REALLY don't want to be losing any data due to someone forgetting this little bit of information. Can we at least get a big glaring warning when getlatest generates a drop statement?
We may be able to do a decent job of guessing whether a create/drop is actuall a rename and prompt the user to confirm. This could generate a rename SQL script and commit it to source control so that future 'gets' would use the rename script rather than the one automatically generated (which would do a drop/create). Thoughts?
Concerning data dropping: Visual Studio Data Projects solves this quite nicely by backing up the data to a temporary table before making drop/create changes on a table.
Adrian Cearnau commented
How about having a semi-automatic system where the Description field of a column can be used to tell the Red Gate tools what the column's previous name was? A candidate/guessing system would be nice as well, of course.
it will also be hard to follow history in source control...
We hope to look into handling renames in a future release. This is a big problem for tables because your data will also be dropped.