Contents 

AdeptSQL Diff Reference
AdeptSQl Diff versions, history and milestones
Supported versions of MS SQL Server
Getting started
Connecting to databases
Scanning available servers
Saving and opening comparisons
Running from command line
Diff in portable mode
Working with the schema
Viewing schema differences
Ignored Differences
Comparing objects side-by-side
Dragging and dropping schema items
Using schema filters
Generating comparison reports
Customizing the reports
Executing the SQL
SQL errors and warnings
Transaction support
Keyboard shortcuts
Editing commands and keyboard shortcuts
Using keyboard templates
Choosing debugger's key mapping
Comparing table data
DataDiff overview
DataDiff configuration dialog - table-level
DataDiff configuration dialog - columns
Special situations comparing data
Exporting data to Excel
DataDiff Reports
Column configuration file
Configuring AdeptSQL Diff
Options dialog
Schema Scan
Selective Loading
Comparison
Name Comparison
Code Comparison
User-defined types
Indexes and Statistics
Permissions and XProps
Synonyms
Other details to ignore
Scripting
General logic
Side-by-side scripting
Formatting
Identifiers
Schema Level
Tables
Constraints
Default Values
Procedures, Views, etc
Visuals
Text Fonts
Schema Tree
Summary collections
Side-by-Side View
Suppressed dialogs
Data comparison options
General
Scripting
Column Config File
Using COM Automation interface
Automating schema comparison
Automating data comparison
Licensing and contact info
Registration of AdeptSQL Diff
License conditions
Contact information

AdeptSQL Diff Online Help

Prev Page Next Page

Options / Comparison / Permissions and Extended Properties

Top  Previous  Next

opt_permsStarting from version 1.95, the Diff allows fine control over comparison and synchronization of permissions and extended properties. The two are controlled separately, but in similar ways, that is why they are shown on the same options page.  There are four comparison modes for each:

 

· Don't load...   Permissions or xprops won't be loaded at all. Accordingly, they can't take part in comparison and are never scripted. There can be no dependencies on either xprops or permissions, so turning them off completely wouldn't make any scripts unusable (as could happen, for example, if you don't load statistics). However, if any object is dropped and re-created during the synchronization,  the Diff would be unable to restore permissions or xprops for it.  We recommend that you only use the "Don't load" setting when you need to minimize loading time (e.g. when connecting to a remote server via dial-up)  and when you are positively sure the target database doesn't contain any permissions / xprops worth preserving.
· Ignore changes... / Preserve XProps... The permissions or xprops are loaded, but not synchronized.  Whenever the Diff has to re-create an object, it will also restore its permissions and/or xprops as they originally were in the target database.  This is the most logical setting, at least for the permissions.
· Only compare if user is present in both DBs / Changed xprops synched... The wording is different for permissions and for xprops, but the meaning is very similar.  For permissions, if the same user is defined in both databases, permissions for that user are synchronized. The Diff won't try to script permissions for the user not defined in the target DB and it will re-create permissions for the users which only exist in the target DB.  For extended properties, it means that xprops with the same name (but different values) are synchronized, but the Diff won't add new xprops to the target and would re-create, when necessary, those that only exist in the target.
· Always compare... / Synchronize all... All permissions / xprops are compared and synchronized in a regular way.

The last option to mention is  "Optimize permissions", which allows not to consider as differences and not to include in scripts certain types of redundant permissions.  Currently the detected redundancies include:

· Granting/denying on column level what is already granted/denied on object level,
· Granting a particular kind of access (e.g. SELECT) when it is already implied (e.g. by granted CONTROL)

There are some more optimizations that might be worth doing, but that are not implemented in the current Diff version (1.96):

· Granting/denying to a user what is already granted/denying to a group/role the user belongs to;
· Granting/denying permissions that already exist on the schema or database level.
   
Converted from CHM to HTML with chm2web Standard 2.85 (unicode)