Home/ Questions/Q 7758477
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T13:22:15+00:00

I recently started a new personal project to learn Entity Framework. My end goal

  • 0

I recently started a new personal project to learn Entity Framework. My end goal is to make a desktop game that uses SQL compact for data management and uses Entity Framework for the game objects. Not actually knowing there were multiple ways to start EF (model first, code first, db first) I went with the most obvious choice of model first.

I’ve been working with it successfully now, however one thing concerns me, especially post-development. My goal with the game is that users can update to the latest version without losing any of their existing data. The current issue is that all the generation scripts are destructive by nature (dropping everything then recreating it) – that means I can’t run those against the user SQLCE DBs out in “production”, so I need to come up with an alternative plan of action.

That said, does anyone have recommended solutions on best practices? In previous desktop apps, I’ve traditionally used XML/binary to store data, which allows me to easily update the “schema” without affecting existing data (versioning in the app tailors the Load() according to the version, while the Save() always saves in the latest version).

What are some recommendations on handling this problem using SQLCE?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What you need, if understood right, is to utilize migrations which come with EF. Since the question is general this link should best guide you to what you need I think…

    http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx

    With migrations which you can tailor manually if needed (and come in the shape of code which is applied at each point of change, incrementally) and you can also supply your ‘seeding’ if required.
    i.e. you should be able to do most of what you require, delete, remove old incompatible data – and seed the new one that you have – and all related to a particular migration step you have.

    How would that work with your app deployment specifically, that’s a bit more complex I guess, but this should get you started, and then with each db version-breaking change your new code update would contain all the migrations since the previous update (or just one usually is enough, i.e. make it be one with each update) and the code to tear-down or create new things.

    hope this helps,

    • 0