The synchronization process merges the packaged reference data from the source into the plant and application reference data at the target. You cannot synchronize selected parts of the packaged reference data, but must synchronize all or nothing.
The synchronization process initiates transactions for each schema that will be modified. If the merge fails, the transactions are rolled back and any added columns are dropped. The reference data files are merged last. All synchronization operations are logged as generic text strings.
-
A plant cannot be synchronized if the comparison process returned any items with errors.
-
You must have site administrator or full access privileges at the target plant before you can synchronize the reference data.
-
The synchronization process does not delete items in the target if those items do not exist in the source.
-
If the synchronization fails, you must extract any original reference data files from the archive to undo the change.
-
Filters that exist in the source and target plants with different UIDs may not have identical names. The filter names must be unique in the source and target for synchronization to proceed successfully.
During the synchronization process, RDS Manager logs synchronization operations and archives modified reference data files to the files described below. These files are located in the Reference Data Synchronization Logs folder created in the target plant folder.
Synchronization Log Files (RdsSync%SerialD%.log)
The synchronization log file, created new each synchronization session, contains the following information:
Session start time
Local date
SerialD
Session serial number
Location
Path to the RDS package
GUID
Unique identifier for the package
Site server
INI filename and plant name
Application names
Synchronization Archive Files (RdsSync%SerialD%.zip)
An archive zip file is created for each synchronization session and contains the following target reference data files if they are flagged for replacement during the comparison process. Each file is archived to this zip file before it is replaced by the corresponding file from the source package. The full path is saved when a file is added to the zip file.
Plant format file
Application symbols (catalog root)
Application rules file
Application styles file
Application insulation specifications
Reports
Templates and borders
Synchronization Tasks
Synchronizing Codelists
Codelist enumerations and entries may be new or updated. Codelist numbers and indexes retain their original values when being added to a plant. Only the compared properties that did not match are updated for existing codelists.
Synchronizing Item Attributes
Synchronizing item attributions affect the following data dictionary tables:
Merging Item
Can be updated only. Only the compared properties that did not match are updated.
Merging attributes
Only the compared properties that did not match are updated for existing attributes. New attributes that have ID conflicts receive a new ID. All item attribution data (uniqueatts) that references the new attribute is updated to reference the new ID.
Merging uniqueatts
Only the compared properties that did not match are updated for existing uniqueatts. New uniqueatts that have ID conflicts receive a new ID. All item attribution data (ItemAttribution) that references the new uniqueatt is updated to reference the new ID.
Merging ItemAttribution
Only the compared properties that did not match are updated for existing ItemAttributions. New ItemAttributions that have ID conflicts receive a new ID. All item attribution data (Filter criteria, Layout attributes and sorts) that references the new ItemAttribution is updated to reference the new ID. A new column is added in the plant or application schema for new ItemAttributions. If the plant is As-Built, then the corresponding schema of each project receives a new column.
Synchronizing Application Filters
Several application data dictionary and schema tables are updated when synchronizing filters. Most of the IDs connecting the filter data together are created during this process. Filter data that does not belong to the target plant is not synchronized.
The filter data is actually merged. In other words, existing Categories and Filters remain in the target plant if they do not conflict with anything in the source package, which may be lead to unexpected results.
Merging Category
Only the compared properties that did not match are updated for existing categories. New categories that have ID conflicts receive a new ID. Referenced by Category.ParentCategoryID and CategoryFilter.CategoryID.
Merging CategoryFilter
CategoryFilter ties the categories to the filter instances. Information may be added or modified to CategoryFilter to connect the new or updated categories and filter definitions to the filter instances. ID is created as needed. Referenced by Category and FilterInstance.
Merging FilterInstance
FilterInstance ties one or more instances of a filter definition to one or more categories. Information may be added or modified to FilterInstance to connect a category to a new or updated filter definition or new instances of existing filter definitions. Most references to filters by ID are to FilterInstance.ID (not Filterdefiniton.ID). Referenced by CategoryFilter.FilterInstanceID, FilterInstance.ParentFilterID, T_OptionDispSet.FilterID, T_OptionAutoGap.FilterID and T_OptionSymbology.FilterID.
Merging FilterDefiniton
FilterDefiniton contains the filters used by an application. Only the compared properties that did not match are updated for existing FilterDefinitons. New FilterDefinitons that have ID conflicts receive a new ID. Referenced by ID from FilterInstance.FilterDefinitionID, FilterCriteria.FilterDefinitionID and SPTPViews.DefaultFilter. Referenced by name in application rules.
Merging FilterCriteria
FilterCriteria contains the criteria information of each filter definition. The filter criteria in the plant is replaced with the filter criteria in the package if any of the criteria has been changed or is new for existing filters. New ID values are generated as needed. Referenced by FilterDefinition.
Synchronizing Application Layouts
Merging SPTPViews
Only the compared properties that did not match are updated for SPTPViews. Referenced by SPTPLayouts.SPTPViews_ID.
Merging SPTPLayouts
Only the compared properties that did not match are updated for SPTPLayouts. New Layouts that have ID conflicts receive a new ID. Referenced by SPTPAttributes.SPTPLayouts_ID.
Merging SPTPAttributes
Only the compared properties that did not match are updated for SPTPAttributes. New SPTPAttributes that have ID conflicts receive a new ID.
Merging SPSorts
Only the compared properties that did not match are updated for SPSorts. New SPSorts that have ID conflicts receive a new ID.
Synchronizing Option Data
-
For SmartPlant P&ID, option tables include T_OptionAutogap, T_OptionHeatTrace, T_OptionFormat, T_OptionSymbology, T_OptionDispSet, T_OptionDispSetFolder and T_ Preferences. Only the compared properties that did not match are updated for option data. Because SP_IDs are GUIDs, new option data items retain their original SP_ID.
-
For SmartPlant Electrical, option tables include T_OptionFormat only.
Synchronizing Reference Data Files
A reference data file (such as rules file, insulation specification file, styles file, reports, templates, and borders) at the target is replaced only if it has been changed. All reference data files marked for replacement are archived at the target and for SmartPlant P&ID, the affected drawings are flagged for update in Drawing Manager.