Eu sei que não há uma maneira direta de fazer o downgrade de um banco de dados do formato de 2008 para o de 2005, infelizmente.
A maneira como eu fiz isso no passado (na verdade, com versões mais antigas do SQL Server, mas o processo será o mesmo) é:
- Restaure o banco de dados em uma instância do SQL2008, se ainda não o tiver feito
- Crie um banco de dados vazio com as estruturas corretas (tabelas, índices, restrições, visualizações, procs, gatilhos, ...) em uma instância do SQL2005. Espero que você possa fazer isso usando o procedimento de compilação existente e / ou o código-fonte, mas, se não, poderá usar o SQL Server Manager para criar scripts para tudo no banco de dados de 2005 e executar o resultado em branco na instância de 2008.
- Verifique se as duas instâncias podem se ver (ou seja, não há firewalls bloqueando conexões se as instâncias estiverem em máquinas diferentes) e vincule-as usando sp_addlinkedserver .
- Copie todos os dados de um banco de dados para o outro. Se não houver restrições de chave estrangeira e problemas semelhantes nos gatilhos para se preocupar, basta vincular os bancos de dados e percorrer a lista de tabelas (selecionando-os em sys.objects) e em execução
INSERT destinationserver.destinationdb.schema.table SELECT * FROM sourcedb.schema.table
(ou INSERT schema.table SELECT * FROM sourceserver.sourcedb.schema.tablese você tiver vinculado as instâncias dessa maneira )
para cada tabela. Se você tiver consistência entre tabelas que impõe restrições e gatilhos, é claro que precisará ser um pouco mais inteligente sobre a ordem dessas operações, especialmente se você tiver restrições cíclicas como uma tabela com uma restrição baseada em si mesma (uma hierarquia de retenção dados, como um possível exemplo).
Pode ser mais eficiente copiar os dados primeiro e adicionar toda a outra estrutura (índices, procs, gatilhos, ...) após a etapa 3. Isso evita problemas de pedidos de inserção de linha causados por restrições e gatilhos e a criação dos índices no diretório O fim deve, em teoria, ser mais rápido do que construí-los à medida que todos os dados são adicionados - embora se você tiver índices agrupados em suas tabelas, crie-os antes de adicioná-los, pois eles não seriam mais rápidos de criar após o fato.
É claro que tudo isso pressupõe que nenhum de seus objetos use recursos específicos do SQL 2008 - se o fizerem, esperamos que você descubra e corrija essas coisas quando ocorrer algum erro ao reconstruir o esquema. Se algum do seu código se basear em um comportamento oficialmente indefinido que varia entre as versões do SQL Server, você poderá ter alguns bugs muito mais sutis e evasivos para descobrir e resolver mais tarde.