locked
How to Get Migration History Up To Date RRS feed

  • Question

  • I normally use code first data migration (4.1) to make small changes.  However, when I make larger changes, I prefer to use a tool like redgate's sql compare and make the changes in mass.  After I've done this, that is comparing my local development that code first created from scratch, to a production server, then I run the hand generated sql on production to bring it up to date, how can I mark the production server so it thinks it is up to date?

    clear?


    Peter Kellner http://peterkellner.net Microsoft MVP • ASPInsider

    Saturday, July 28, 2012 8:06 PM

All replies

  • Why don't you use automatic migration, it could help you update the database to the latest version. : >

    Go go Doraemon!

    Monday, July 30, 2012 2:42 AM
  • AutoMigrations is great for small changes but my experience has been it's very painful to use when you do any kind of restructuring or things where data loss will occur.  

    Peter Kellner http://peterkellner.net Microsoft MVP • ASPInsider

    Monday, July 30, 2012 2:43 AM
  • How about requesting support here. They may have ideas on how to identify the version of the database. Based on the description, I believe you are not the only one meet this scenario, I hope you can solve it and share the experience here.
    Monday, July 30, 2012 7:22 AM
  • Hi pkellner,

    Do you mean, you're using redgate's sql compare tool and after updating the database, you want to let the production server realize it is up to date now? If yes, I agree with @Doraemon_3, it is better to consult redgate support. If I understand incorrectly, please feel free to let me know. : )

    Best Regards


    Allen Li [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, July 31, 2012 4:58 AM
  • Hi Allen,

    I'm thinking I should not have mentioned redgate.  All redgate is doing for me is creating a complex sql script, then it is totally out of there hands.  What I'm wanting to do is somehow either get that complex script in my migration history, or better yet, have EF CodeFirst mark the changed database as current.  I really don't understand all the details of what goes on under the covers.  I am uncomfortable asking redgate because my issue has nothing to do with the sql script they generated.

    thanks


    Peter Kellner http://peterkellner.net Microsoft MVP • ASPInsider

    Tuesday, July 31, 2012 5:15 AM
  • You can have a table in your database to identify the version of the database. Every time you update the database, you should update this table. 
    Tuesday, July 31, 2012 6:45 AM
  • Hi pkellner,

    I have involved some senior engineers to research this issue, it may need some time, thanks for your understanding. : )

    Best Regards


    Allen Li [MSFT]
    MSDN Community Support | Feedback to us

    Friday, August 3, 2012 1:34 AM
  • It is not possible to inject custom SQL script inside migration history. I am going to file a feature request on this.
    • Marked as answer by Peter Kellner Friday, August 3, 2012 4:52 PM
    • Unmarked as answer by Rowan Miller Friday, August 3, 2012 5:14 PM
    Friday, August 3, 2012 4:34 PM
  • thanks!

    Peter Kellner http://peterkellner.net Microsoft MVP • ASPInsider

    Friday, August 3, 2012 4:52 PM
  • Hey Peter,

    I'd like to understand a little more about your scenario before giving you guidance. You mentioned that you are using EF4.1 but I'm guessing you are actually using EF4.3 or later because Code First Migrations wasn't introduced until EF4.3. Is that correct?

    Code First Migrations is designed to provide a set of steps that can be used to upgrade/downgrade on any server... so if you are applying changes directly to the database that breaks. Before we dig into how to support your scenario though, can you let me know what causes you to need to apply changes directly to the database rather than just scaffolding the next migration and applying it to the database?

    ~Rowan


    The *Pre-Release* Entity Framework Forum will be closing soon. We are seeing a lot of great Entity Framework questions (and answers) from the community on Stack Overflow. As a result, our team is going to spend more time reading and answering questions posted on Stack Overflow. We would encourage you to post questions on Stack Overflow using the entity-framework tag. We will also continue to monitor the Entity Framework forum.

    Friday, August 3, 2012 5:13 PM
  • Hi Rowan,

    You are right.  The version I see in the system.data.entity is 4.0.303191.

    I'm sure I am not using Migrations as well as I should.  Besides originally using the powershell commands to set up migrations and the migrations folder (and the table), I have not done anything with the powershell commands.  

    To get from one version to another, I've simply launched my program and let it do the upgrade, which for non data hurting changes has worked great.  Since I'm still in development and I recreate my data with seeding, if there are braking changes, I simply drop my database and let EF create a new one with the new tables.

    My problem is that when I make complex changes that include things like renaming tables, refactoring relationships, etc, I think there is little chance migrations will figure out the changes necessary once (and also the appropriate data movements).  I've found redgate is very good at generating a script for this and I simply add my own custom stuff to the script for taking care of data loss and movement issues (for example if I refactor a relationship that requires moving data from a base table into a detail table including column name changes and possibly types.  What I would like to happen is have the ability to be able to take my huge script and stuff it into the migration with a mark that says upgrade only.  Then, it will run automatically at the correct time and just fix my database for me.

    Let me know if my thinking is off base here.  I'm sure I could be using Migrations much better.  Also, thanks for all your work on CF and Migrations.  You have made my life so much simpler than it use to be.


    Peter Kellner http://peterkellner.net Microsoft MVP • ASPInsider

    Friday, August 3, 2012 7:03 PM
  • BTW, I wrote a short post on using RedGate tools for this:  http://peterkellner.net/2012/07/29/using-redgates-sql-compare-for-complex-migrations-with-efs-codefirst/  Feel free to comment on it if I said anything wrong or could be said more clearly regarding code first.  My feelings will not be hurt.

    Peter Kellner http://peterkellner.net Microsoft MVP • ASPInsider

    Friday, August 3, 2012 7:05 PM