March 5, 2013 at 3:10 pm
I know there is little written about the data tier architecture, and I have read the white papers, etc.. but it seems strange in an application designed for moving sql projects from devt to production that there is no way of stopping the dropping of the existing security that is on the Prod environment. Let me expand...
Steps:
1/ Have a working devt, etc envs configured with a devt, test... configurations (data tier registrered)
2/ Have a working Prod env configured with a prod configuration (data tier registrered)
3/ Have a release candidate on the devt machine
4/ Export the data tier at the devt rc (which contains all the devt security; You can exclude the security from the created package, if using Visual Studio or not if directly from SSMS)
5/ Upgrade the prod env....Wait! Even though I removed the devt security, the comparison of the schemas has told slq to drop all the current prod users/logins/schemas that were not on the devt env (which is basically the prod security)..:w00t:Doh!
How can you remove the comparison of the security - Add to the built dacpac the production security(lame and has further complications re SQL logins needing to be re-enabled and if on differing domains; What about windows logins)?? How were they thinking this would work in a production deploy?
If you have an idea, or can see I am missing something please let me know.
SQL DBA
Every day is a school day, and don't trust anyone who tells you any different.
http://sqlblogness.blogspot.co.uk
Viewing 0 posts
You must be logged in to reply to this topic. Login to reply