Answered Refactor -> Rename Problem

  • Wednesday, March 24, 2010 6:13 PM
     
     

    As a test, I selected a table in our schema and did a Refactor -> Rename on it. After the operation completed successfully, I noticed a .RefactorLog file was created, which I assume is good. I then did a Schema Compare where the source is our project and the target is a database that has the same schema as the project, except for the table rename.

    The schema compare results show a table drop, and a table add instead of a table rename. This is clearly wrong. Why isn't the schema compare generating a table rename?

    Thanks.

Answers

  • Wednesday, March 24, 2010 7:49 PM
    Moderator
     
     Answered

    Hi Randy,

    Schema Compare does not comprehend the refactoring log.  Only project deployment comprehends the refactoring log.  If you deployed your project to the target database you will find the refactor operation will be run.  Adding refactoring support to Schema Compare is on the product backlog for a future version.

    Thanks,


    Barclay Hill Program Manager Visual Studio Data Tools (DataDude, DBPro, Database Edition, Database Projects, VS Data Tools) Please mark the responses as the answer if it resolves your question/issue. http://blogs.msdn.com/bahill

All Replies

  • Wednesday, March 24, 2010 7:49 PM
    Moderator
     
     Answered

    Hi Randy,

    Schema Compare does not comprehend the refactoring log.  Only project deployment comprehends the refactoring log.  If you deployed your project to the target database you will find the refactor operation will be run.  Adding refactoring support to Schema Compare is on the product backlog for a future version.

    Thanks,


    Barclay Hill Program Manager Visual Studio Data Tools (DataDude, DBPro, Database Edition, Database Projects, VS Data Tools) Please mark the responses as the answer if it resolves your question/issue. http://blogs.msdn.com/bahill
  • Wednesday, March 24, 2010 8:47 PM
     
     

    Barclay,

    This is a little hard to believe. Certainly you realize that most developers will do many schema compares to and from local development databases before a deployment is ever done. How are we supposed to synchronize these refactoring changes to and from local development databases, by going through the full deploy process? 

    Randy

  • Wednesday, March 24, 2010 11:23 PM
    Moderator
     
     

    Yes, the iterative deployment cycle the product is designed to support against a sandbox database is through deployment, not schema compare.  Schema Compare has been designed with the intent that it is used to cherry pick changes between sources and targets. Refactoring support in Schema Compare just has not made it up high enough to be added to the product in 2010, but is still on the product backlog for a future release. We will consider your post as supporting evidence that it should be higher.

    Thanks,


    Barclay Hill Program Manager Visual Studio Data Tools (DataDude, DBPro, Database Edition, Database Projects, VS Data Tools) Please mark the responses as the answer if it resolves your question/issue. http://blogs.msdn.com/bahill
  • Wednesday, March 24, 2010 11:23 PM
    Moderator
     
     

    Yes, the iterative deployment cycle the product is designed to support against a sandbox database is through deployment, not schema compare.  Schema Compare has been designed with the intent that it is used to cherry pick changes between sources and targets. Refactoring support in Schema Compare just has not made it up high enough to be added to the product in 2010, but is still on the product backlog for a future release. We will consider your post as supporting evidence that it should be higher.

    Thanks,


    Barclay Hill Program Manager Visual Studio Data Tools (DataDude, DBPro, Database Edition, Database Projects, VS Data Tools) Please mark the responses as the answer if it resolves your question/issue. http://blogs.msdn.com/bahill
  • Thursday, March 25, 2010 1:16 AM
     
     

    Barclay,

    I think one thing the designers of DBPro has overlooked is the fact the a large percentage of developers who've come to use DBPro probably came from a Red-Gate SQL Compare environment where a schema compare and then an update to a target database was how we did everything!

    One other comment. You said that schema compare was designed to "cherry pick changes" between sources and targets. IMHO, DBPro misses the mark on this. It is not at all easy to "cherry pick" changes. Your schema compare UI is not nearly as user friendly as Red-Gate SQL Compare and it can be downright frustrating to have to drill down three to four levels deep on an object just to see what changed.

    Don't get me wrong, I like the product. IMO, it's the best there is at managing and version controlling schema. But some of the design decisions your team has made regarding the product leave me scratching my head sometimes.

    Randy

  • Tuesday, July 12, 2011 9:35 PM
     
     

    This is a major problem. We use the Schema Compare to create scripts that are then sent to customers to execute on their systems. Now I find that when I rename a column, I have no way to automatically create a script using Schema Compare (from my project to our development database) that I can deploy at a customer's site without causing data loss! Is there a workaround for this?

    We didn't buy Red Gate SQL Compare because VS 2010 seemed to do what we needed for no additional cost. If there is no reasonable workaround, I won't have much choice.