I have read this blog: which explains the difference between Database Initializer seeds and Migration seed methods.
I am working on a project, that uses code-first Entity Framework, with migrations enabled. A Database Initializer seed is present and it will execute on my local database, when the database is created.
But in the production environment, I do not have the rights to add databases myself. I need to run update-database -script from package manager console on an empty newly created database and then execute the migrations manually.
As I do not have direct access from my development environment to the production database server, I am thinking out loud: there is no gain in rewriting the Database Initializer to a Migrations Seed.
How can I obtain the script (SQL), that is the insert statements, defined in the Database Initializer seed method?
Of course I can :
- run update-database on an empty existing database. (no seed method is executed)
- run update-database on a non-existing database. (seed method is executed)
Do a SQL compare between the 2 databases and get the INSERT queries that way.
But there should be an easier way right?
Why does the update-database -script
not show the INSERT statements from the database initializer seed method in the first place?
I am not sure if the logging described in Entity Framework Logging and Intercepting Database Operations will catch the SQL from the DatabaseInitializer. If not you can try to find a 3rd party profiler to catch your SQL. Personally, I use ORM Profiler and it catches everything, however it is not free.
And yes, there should be an easier way.