Comments
4 comments
-
Thanks for reporting this issue!
I'll speak it with the development team and get back to you. -
Just want to let you know the development team has confirmed this is a bug and will investigate it!
Thanks. -
Thanks for your patience.
I'm pleased to let you know the fix has been released in 14.0.4.13251. Please upgrade at your convenience.
Thanks. -
Tianjiao_Li said:Thanks for your patience.
I'm pleased to let you know the fix has been released in 14.0.4.13251. Please upgrade at your convenience.
Thanks.
Thanks for the quick turnaround!
Chris
Add comment
Please sign in to leave a comment.
Steps to Replicate
I've attached a sample set of scripts that can be used to replicate the problem, but the steps are here:
1. In the script folder create a script for a login and user named: MYDOMAIN\intranet
2. In the script folder create a script for a role named: zrIntranet
3. In the script folder create a script for a role named: intranet
4. To the relevant script add a statement to make the 'intranet' role a member of the 'zrIntranet' role
5. Use the SQL Compare GUI to compare the script folder with itself (scripts vs scripts just to keep it simple and show the behaviour - issue also occurs with DB vs script folder, but only on the script folder side)
Expected Behaviour
I would expect SQL Compare to identify that the 'intranet' role is a member of the 'zrIntranet' role. The user should not belong to any role.
Actual Behaviour
SQL Compare decides that the 'MYDOMAIN\intranet' user is a member of the 'zrIntranet' role, ignoring the actual role membership defined in the script folder.
SQL Compare 14.0.0.12866 Professional
Is this a known issue?
Thanks
Chris