In order to gain access to the SQL Instance, our standard SQL User  and Login was defined up front.

We want to deploy a standard database, which, of course, has that User, but being from another instance, the SID is different, just like it would be from a cross-instance database RESTORE, where we typically run an orphan-cleanup script to realign such SIDs.

The five-hour deploy was wasted because the CREATE USER [stduser] statement bombed with an already-exists error.  This, IMO, is entirely unnecessary.  Generate the BacPac such that if it finds the USER, realign the SIDs, otherwise run the CREATE.

So far, I've wasted four five-hour deployments because the apply-to-target step bombs with the first error, rather than try to apply what it can in toto, giving me all the issues in one hit.

Anything the Azure SQL DB Team can do to make our deployment frustrations fewer, please?

Hi SAinCA,

My apologies that you've run into issues when importing a bacpac.  From your post it's a little unclear to me what sequence of steps you've taken. Could you describe the steps I'd need to take to reproduce this problem behavior?

Thanks!

Very simple, purely using SSMS Deploy wizard, with our "normal" sa-equivalent SQL Login added to the Azure logins, which is where the eventual SID conflict originates.

1. Cleanup initial "not supported" items.
2. Deploy.
3. Watch GBs of tables get exported.
4. Bomb at the final stages because the sa-equiv SID from our database doesn't match the cataloged sa-equiv SID in Azure.

It is common practice when restoring databases across instances to perform an "orphan login check" and resolve same-name logins' SID.  Easily done.  Effective.  Correct.

Deploy to Azure is essentially a restore to another instance, thus the same rules should apply: accept the SID mismatch and allow us to resolve it in the usual way.

We will not be deploying from a single instance - probably true, too, for many Azure SQL DB customers.  Thus, SID mismatches will constantly occur and must not, EVER, be a roadblock to deployment.

I hope this clarifies what should be trivial to fix.