Skip to content
← SQL Source Control

How can we improve SQL Source Control?

SQL Source Control

Categories

JUMP TO ANOTHER FORUM

(thinking…)

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?

55 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
anonymous shared this idea  ·   ·  Report…  ·  Admin →

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Benny Bech commented  ·   ·  Report

    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)

  • AdminChris Smith (Project Manager - SQL Lighthouse, Redgate) commented  ·   ·  Report

    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:
    https://www.surveymk.com/s/SqlSourceControl_Download

    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.

  • jbWild commented  ·   ·  Report

    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  ·   ·  Report

    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?

  • AdminDavid Atkinson (Product Manager, Redgate) commented  ·   ·  Report

    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?

  • Adara commented  ·   ·  Report

    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  ·   ·  Report

    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.

  • Jerome commented  ·   ·  Report

    it will also be hard to follow history in source control...