1

Issue:

When running sqlpackage.exe to apply a sql dacpac, it occasionally fails on broker/SignalR related objects, which breaks the build:

*** 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];

This is our sqlpackage.exe cmd line parameters:

/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

Again, the failure rate is like 1 out of every 10 runs, and no one is manually removing these objects, thus I have no idea why it would not be able to drop the object if it knows about it. Any ideas on a good solution to get it to apply consistently ?

SqlWorldWide
  • 13,687
  • 3
  • 30
  • 54
Greg
  • 582
  • 1
  • 4
  • 14

1 Answers1

2

Again, the failure rate is like 1 out of every 10 runs, and no one is manually removing these objects

Although no one is manually dropping these objects, it seems SqlDependency is used to detect database changes. SqlDependency creates/drops ephemeral objects so, if the application is running during publish with the with the /p:DropObjectsNotInSource=True option, the object might longer exist when the deployment script is executed by sqlpackage.

One option is to stop the application while the dacpac is published. You could also exclude the problem objects during publish (e.g. using the DoNotDropObjectTypes option).

Dan Guzman
  • 28,989
  • 2
  • 46
  • 71