Lamentablemente, no hay una manera directa, que yo sepa, de degradar un DB del formato de 2008 al 2005.
La forma en que lo hice en el pasado (en realidad con versiones anteriores de SQL Server, pero el proceso será el mismo) es:
- Restaurar la base de datos en una instancia de SQL2008 si aún no lo ha hecho
- Cree una base de datos vacía con las estructuras correctas (tablas, índices, restricciones, vistas, procesos, disparadores, ...) en una instancia de SQL2005. Esperemos que pueda hacer esto desde su procedimiento de compilación existente y / o código fuente, pero si no puede usar el Administrador de SQL Server para crear scripts para todo en la base de datos 2005 y ejecutar el resultado en blanco en la instancia de 2008.
- Asegúrese de que las dos instancias puedan verse entre sí (es decir, que no haya firewalls que bloqueen las conexiones si las instancias se encuentran en máquinas diferentes) y vincúlelas utilizando sp_addlinkedserver .
- Copie todos los datos de un DB a otro. Si no hay restricciones de claves externas y problemas similares en los desencadenantes de los que preocuparse, puede vincular los DB juntos y pasar por la lista de tablas (seleccionándolos de sys.objects) y ejecutar
INSERT destinationserver.destinationdb.schema.table SELECT * FROM sourcedb.schema.table
(o INSERT schema.table SELECT * FROM sourceserver.sourcedb.schema.tablesi ha vinculado las instancias de esa manera) )
para cada mesa. Si tiene constricciones y desencadenantes que imponen coherencia entre tablas, por supuesto necesitará ser un poco más inteligente sobre el orden de estas operaciones, especialmente si tiene restricciones cíclicas como una tabla con una restricción basada en sí misma (una jerarquía de retención datos, como un posible ejemplo).
Puede ser más eficiente simplemente copiar los datos primero y agregar todas las demás estructuras (índices, procesos, desencadenantes, ...) después del paso 3. Esto evita problemas de orden de inserción de filas causados por restricciones y desencadenantes, y la construcción de los índices en el En teoría, el final debería ser más rápido que crearlos, ya que se agregan todos los datos, aunque si tiene algún índice agrupado en sus tablas, créelos antes de agregar los datos, ya que no sería más rápido crearlos después del hecho.
Por supuesto, todo esto supone que ninguno de sus objetos usa características específicas de SQL 2008; si lo hacen, con suerte descubrirá y arreglará esas cosas cuando las cosas tengan un error al reconstruir el esquema. Si alguno de sus códigos se basa en un comportamiento oficialmente indefinido que puede haber variado entre las versiones de SQL Server, es posible que tenga errores mucho más sutiles y esquivos para buscar y resolver más tarde.