Questão:
Ao executar sqlpackage.exe para aplicar um sql dacpac, ele ocasionalmente falha em objetos relacionados ao broker/SignalR, o que interrompe a compilação:
*** Could not deploy package.
Error SQL72014: .Net SqlClient Data Provider: Msg 15151, Level 16, State 1, Line 1 Cannot drop the service 'Xxxxxx_xxxxx_0de7d69e-48ac-4a2b-95ef-d758d69b2a1e_Receiver', because it does not exist or you do not have permission.
Error SQL72045: Script execution error. The executed script:
DROP SERVICE [Xxxxxx_xxxxx_0de7d69e-48ac-4a2b-95ef-d758d69b2a1e_Receiver];
Estes são os nossos sqlpackage.exe
parâmetros de linha cmd:
/p:TreatVerificationErrorsAsWarnings=True /p:DoNotAlterChangeDataCaptureObjects=True /p:DropIndexesNotInSource=True /p:DropObjectsNotInSource=True /p:ExcludeObjectTypes=Users;Logins;RoleMembership;Permissions;Credentials;DatabaseScopedCredentials;LinkedServerLogins;LinkedServers /p:BlockOnPossibleDataLoss=False
Novamente, a taxa de falha é como 1 em cada 10 execuções, e ninguém está removendo manualmente esses objetos, portanto, não tenho ideia de por que não seria capaz de descartar o objeto se soubesse disso. Alguma idéia de uma boa solução para que ela seja aplicada de forma consistente?
Embora ninguém esteja descartando manualmente esses objetos, parece que
SqlDependency
é usado para detectar alterações no banco de dados. SqlDependency cria/remove objetos efêmeros, portanto, se o aplicativo estiver sendo executado durante a publicação com a/p:DropObjectsNotInSource=True
opção, o objeto poderá existir mais quando o script de implantação for executado por sqlpackage.Uma opção é parar o aplicativo enquanto o dacpac é publicado. Você também pode excluir os objetos problemáticos durante a publicação (por exemplo, usando a
DoNotDropObjectTypes
opção).