Supongamos que tiene un proyecto de base de datos y NO tiene marcada "Volver a crear siempre la base de datos" en la configuración de Database.sqldeployment. Y supongamos que se despliega en un servidor que ya tiene una base de datos por el nombre de la que está implementando.¿Cómo previene que una implementación de proyecto de base de datos VS2010 genere una base de datos drop?
¿En qué otras circunstancias la base de datos se desplegará generará un script con una declaración "DROP DATABASE"?
Si alguna vez, alguna vez desea que su base de datos caiga mediante la secuencia de comandos de despliegue generada al hacer clic derecho en su proyecto de base de datos y seleccionar "Implementar", ¿cuáles son algunos de los pasos que puede seguir para evitarlo?
¿Alguna posibilidad de que pueda publicar los archivos de proyectos y configuraciones? AFAIK la opción que mencionaste es la única que provocaría que una DROP DATABASE esté programada. –
Lamentablemente, no, porque el proyecto pertenece al cliente. Además, ni siquiera puedo reproducir esto. El proyecto ahora genera el script sin la caída. Estoy tratando de descubrir qué pudo haber causado que generara el script con un drop anterior. Frank, a continuación, tuvo una buena idea sobre la conexión de destino. Aunque se estableció la conexión de destino, es posible que se haya configurado solo en la configuración de mi proyecto y no en la configuración de mi entorno aislado. También consideré que quizás tener una conexión de destino definida, pero no ser VPN podría haberlo causado. idk. –
Ah, eso tiene sentido. Sí, el desarrollador aislado vs la configuración del proyecto puede ser un poco confuso. Me alegro de que abandonaron esa idea en SSDT. ¿Recuerda si la implementación se realizó de forma interactiva o un servidor de compilación la ejecutó por usted? Si fuera el último, podría haber algo útil capturado en el registro de compilación. –