entity framework - tutorial - MVC3 y Code First Migrations: "el modelo que respalda el contexto ''blah'' ha cambiado desde que se creó la base de datos"

mvc 5 entity framework relationships

Question

Comencé mi proyecto usando Entity Framework Code First. Cuando estuve listo, cargué mi base de datos y mi código a mi proveedor anfitrión. Todo funciono

Necesito agregar un nuevo campo a una de mis clases y no quiero perder los datos en la base de datos. Por lo tanto, intenté seguir algunas publicaciones de blog sobre el uso de Code First Migrations. Hice lo siguiente:

1. Hice una copia de seguridad de mi base de datos remota (producción).
2. Adjunté esta base de datos localmente
3. Agregué la propiedad a mi clase
4. PM> Habilitar-Migraciones
5. PM> Add-Migration AddSortOrderToCar
6. PM> Update-Database
7. En este punto, creé un archivo .bak de la base de datos local y luego utilicé ese archivo para ''restaurar'' al remoto.
8. Por último, publiqué el código en el sitio remoto.

Cuando visito el sitio recibo el siguiente mensaje de error: El modelo que respalda el contexto ''blahblah'' ha cambiado desde que se creó la base de datos. Considere el uso de Code First Migrations para actualizar la base de datos.

¿Qué estoy haciendo mal?

Answer 1

Creo que en el paso 6 necesitas ejecutar Update-Database -Verbose

También este enlace es muy útil para actualizar la base de datos en EF con Scaffolding http://www.asp.net/mvc/overview/older-versions/hands-on-labs/aspnet-mvc-4-entity-framework-scaffolding-and-migrations

Answer 2

Desde mi experiencia, eso sugiere que la tabla de migración no está sincronizada (incluso si sus datos no lo están), y eso ahora es parte del esquema de la base de datos (desde la versión 4.3, creo que en las tablas del sistema).

Podría haber muchas razones y maneras de experimentar ese error, pero la mayoría del tiempo ...

La parte problemática es una combinación de respaldo / restauración manual de la base de datos completa con cambios de código al lado, no estoy completamente seguro de por qué siempre.

En resumen, incluso si los Db-s son los mismos, los datos de la tabla de migración podrían no serlo - y la comparación de hash puede fallar (aún la restauración completa parece ser lo suficientemente buena - pero tiene ''dos ​​lados'').

Lo que me funciona es usar
Update-Database -Script

Eso crea un script con una ''diferencia de migración'',
que puede aplicar manualmente como un script SQL en la base de datos del servidor de destino (y debe obtener las filas correctas de la tabla de migración insertadas, etc.).

Si eso todavía no funciona, todavía puedes hacer dos cosas ...

1. Elimine la tabla de migración (destino - debajo de las tablas del sistema) - según http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx comentarios ahí, eso debería volver al comportamiento anterior y, si está seguro de que sus Db-s son iguales, solo va a "confiar en usted",

2. Como último recurso utilicé - hacer un Update-Database -Script del esquema completo (por ejemplo, inicializando una base de datos vacía que debería forzar un ''script completo''),
   encuentre los registros INSERT INTO [__MigrationHistory] ,
   simplemente ejecute esos, insértelos en la base de datos,
   y asegúrese de que sus bases de datos - y el código coinciden,

Eso debería hacer que las cosas corran sincronizadas de nuevo.

(descargo de responsabilidad: esto no es una prueba de balas para que funcione en todo momento, es posible que deba probar algunas cosas en función de sus escenarios locales, pero debe sincronizarlo)