Search

[SSDT] Add publication setting to "Ignore database users" by eskarina

Closed
as Won't Fix Help for as Won't Fix

28
0
Sign in
to vote
Type: Suggestion
ID: 775839
Opened: 1/4/2013 2:03:13 PM
Access Restriction: Public
1
Workaround(s)
Please consider adding a publish setting to "Ignore database users" similar to the existing "Ignore permissions" and "Ignore role membership" settings. Many of our servers & databases have different logins, users, & permissions in different environments. It's extremely challenging to use SSDT to publish to these environments without having to manually modify the publication scripts to clean up unnecessary security-related changes.

Others reporting similar issues:

http://social.msdn.microsoft.com/Forums/en-US/ssdt/thread/1952c253-baf7-4186-844d-9507bce2299d

http://social.msdn.microsoft.com/Forums/en-US/ssdt/thread/00755c1e-3afd-40ee-b907-86d4c23355cc/

http://social.msdn.microsoft.com/Forums/en-US/ssdt/thread/8bf3d70a-60fd-400a-b4fa-8e11ab0d0ea0
Details (expand)

Product Language

English

Category

Developer Tools (SSDT, BIDS, etc.)

Proposed Solution

Add a publish setting to "Ignore database users" similar to the existing "Ignore permissions" and "Ignore role membership" settings.

Primary Benefit

Improved Administration

Other Benefits

 

Virtualization

 
File Attachments
0 attachments
Sign in to post a comment.
Posted by j. moblex on 1/22/2013 at 10:00 AM
So what is the workaround if Dev, Test, UAT, and Production have different database users?
Posted by Microsoft on 1/20/2013 at 8:00 PM
Hey eskarina,

Thanks for reporting this issue regarding a potential deployment option to ignore differences in users when publishing or deploying using SSDT/DACFx. The SSDT/DACFx team is not pursuing a fix for this issue at this time, but we do have an item tacking the issue should it come up for consideration in the future.

Thanks,
Adam Mahood
Program Manager
SQL Server Database Systems
Sign in to post a workaround.
Posted by Buddhatripp on 1/29/2013 at 10:51 AM
The workaround we use is to disable the "Drop Objects Not In Source" option and perform a schema compare against a master database instance (fresh database with the recreate option turned on) then perform the drops in our continuous integration process.

Another approach is to use a pre-deployment script to perform the drops. Just check for existence of the object before executing the drop just like you would do before SSDT came along.