Problemas como este nos muestran que las personas que hacen el servidor SQL nunca han usado su producto. Esta es una omisión tan evidente que uno tiene que preguntarse qué más se olvidaron de hacer correctamente (tengo una lista de otros 30 problemas enloquecedores como este que tuve que superar para que esto funcione como lo hacen otros DB) de la caja; incluido el hecho de que necesitamos un pésimo asistente para hacer esto en primer lugar [si tuviera el tiempo que he pasado esperando que este asistente se conecte y enumere las mismas tablas para el mismo DB, cada vez, de regreso ... tendría tiempo para unas buenas vacaciones]).
Soy muy vago y no quiero escribir EXEC sp_msforeachtable ...
dos veces cada vez que hago esto. Mi trabajo ha sido dejar las restricciones en el servidor de producción y eliminarlas del servidor de desarrollo. Esto evitará el error, pero este método tiene algunos efectos secundarios MUY GRANDES. Primero, ya no podrá restaurar una copia de seguridad completa en su servidor de desarrollo (a menos que esté de acuerdo con eliminarlos de nuevo). En segundo lugar, esto funciona mejor cuando está seguro de que los consumidores de sus datos también imponen estas restricciones (o no les importan). En mi caso, solo tenemos un consumidor (nuestro sitio web), por lo que también hemos incorporado estas restricciones en el código del sitio (es decir, antes de eliminar un registro de usuario, primero eliminamos todos los registros telefónicos de ese usuario). Si, esto esencialmente niega la necesidad de restricciones en primer lugar y duplica el trabajo que necesito hacer, pero también me da la oportunidad de verificar que mi código funcione con o sin restricciones basadas en DBMS (el hecho es que todavía están en el producto servidor solo como un plan de contingencia). Podría llamar a esto una falla en mi diseño, pero prefiero llamarlo una solución para un DBMS defectuoso. En cualquier caso, aún es más rápido y fácil hacerlo en cualquier otro lugar que desde MSSQL porque no puede hacer frente a su propio diseño.
sp_msforeachtable
(ysp_MSForEachDb
) no está documentado ni soportado. No debe / evite usarlo. ¡Puede saltarse las mesas! Vea esta publicación de @AaronBertrand -> sqlblog.com/blogs/aaron_bertrand/archive/2010/12/29/… y este elemento de conexión - (MS indica que no lo solucionarán) -> connect.microsoft.com/SQLServer / feedback / details / 264677 /…