Problemas como esse nos mostram que as pessoas que fabricam o SQL Server nunca realmente usaram seu produto. Essa é uma omissão tão flagrante que é preciso se perguntar o que mais eles simplesmente esqueceram de fazer corretamente (eu tenho uma lista de cerca de 30 outras questões enlouquecedoras como essa que eu tive que superar para fazer isso funcionar como outros DBs o fazem da caixa, incluindo o fato de que precisamos de um assistente ruim para fazer isso em primeiro lugar [se eu tivesse o tempo gasto esperando que esse assistente se conectasse e enumerasse as mesmas tabelas para o mesmo banco de dados, sempre ... eu teria tempo para umas boas férias]).
Sou muito preguiçoso e não quero digitar EXEC sp_msforeachtable ...
duas vezes toda vez que faço isso. Minha solução foi deixar as restrições no servidor de produção e removê-las do servidor de desenvolvimento. Isso evitará o erro, mas esse método tem alguns efeitos colaterais MUITO GRANDES. Primeiro, você não poderá mais restaurar apenas um backup completo no servidor de desenvolvimento (a menos que você consiga removê-los novamente). Segundo, isso funciona melhor quando você tem certeza de que os consumidores de seus dados também impõem essas restrições (ou não se importam com elas). No meu caso, temos apenas um consumidor (nosso site) e, por isso, incorporamos essas restrições no código do site (ou seja, antes de excluir um registro de usuário, excluímos todos os registros telefônicos desse usuário primeiro). Sim, isso basicamente nega a necessidade de restrições em primeiro lugar e dobra o trabalho que eu preciso fazer, mas também me dá a chance de verificar se meu código funciona com ou sem restrições baseadas em DBMS (o fato é que elas ainda estão no produto servidor apenas como plano de contingência). Você pode chamar isso de falha no meu design, mas prefiro chamá-lo de solução alternativa para um DBMS defeituoso. De qualquer forma, ainda é mais rápido e fácil fazer isso em qualquer outro lugar do que no MSSQL, porque é incapaz de lidar com seu próprio design.
sp_msforeachtable
(esp_MSForEachDb
) não está documentado e não é suportado. Você não deve / evita usá-lo. Pode pular as mesas !! Consulte esta postagem em @AaronBertrand -> sqlblog.com/blogs/aaron_bertrand/archive/2010/12/29/… e este item de conexão - (MS indicando que não a corrigem) -> connect.microsoft.com/SQLServer / feedback / details / 264677 /…