Rules for merging databases

The merge process applies rules to each type of record, which determine the tables, records, and values that are used in the merged database, especially when duplicates or near-duplicates are used in both source databases.

Generally, if subsequent databases contain duplicates, the new database will use the values from the first database in the list of databases you select for merging. In some cases, group records (such as group assemblies, crews, and rate tables) in the merged database can appear to be sorted incorrectly because of the renumbering method used during the merge. Where there is a conflict between a group record and a non-group record, the non-group record is used in the merged database, and the group record is renumbered.

For information about when records are considered duplicates and what records are merged in the new database, click the record types below.

• Addons

  Addons are duplicates if they have the same addon number, description, and cost basis. If only the numbers match, the merge process assigns the next available number before adding the addon to the new database.

  Renumbered addons, and addons that cannot be renumbered, are identified in the merge log file.

• Assemblies

  Assemblies are matched by name, description, group setting, and number of details.

  Then, assembly details are compared, in their original order, and matched by type, phase/item, item table, or selection at takeoff. For item assembly details, either the item table names or the phase codes and item codes must match.

  If only the names match, the merge process renumbers the assembly before adding it to the new database. The new name is the original name with a numeral at the end (characters are removed from the right if necessary). For example: 1000 CONC becomes 1000 CONC1.

  Important! If the name of a group assembly record is the same as an assembly record (non-group), the group assembly record is renamed by appending the next available group number, regardless of the order in which the databases are listed. To avoid unexpected results in the merged database, make sure that duplicate names do not exist for group and non-group records among the databases you are merging before you merge databases.

  Renamed assemblies are identified as such in the log file.

• Factor table

  Only the values from the first database are merged.

• Crew Info (_CrewCalc Table)

  Only the values from the first database are merged.

• Crews

  Crews are duplicates if they have the same name, description, group setting (for example, if both are group crews or both are regular crews), number of resources, and resources (including quantities).

  If only the names match, the merge process renames the crew before adding it to the new database. The new name is the original name with a numeral at the end (characters are removed from the right if necessary). For example: ConcForm becomes ConcForm1.

  Important! If the name of a group crew record is the same as a crew record (non-group), the group crew record is renamed by appending the next available group number, regardless of the order in which the databases are listed. To avoid unexpected results in the merged database, make sure that duplicate names do not exist for group and non-group records among the databases you are merging before you merge databases.

  Renamed crews are identified as such in the log file.

• Default spreadsheet sort sequences

  Only the values from the first database are merged.

• Formulas

  Formulas are duplicates if they have the same name (including capitalization) regardless of the actual equation.

  If a formula is replaced by a duplicate record with a different equation, the old and new equations appear in the merge log file.

• Formula tables

  Formula tables are duplicates if they have the same name, regardless of the contents of the table itself.

• General settings

  Only the values from the first database are used in the merged database—except for the default total Totals template, which uses the first non-blank reference.

• Item sort sequences

  Only the values from the first database are merged.

• Items

  Items are duplicates if they have the same phase/item code.

  The merge process preserves price links.

• Item tables

  Item tables are duplicates if they have the same name and column selector.

• Material classes

  Material classes are duplicates if they have the same BOM descriptions (including capitalization).

• Models

  The rules for merging model records are shown below.

  • Model records are merged even if Model Estimating is not installed on a workstation that uses the Merge Database feature.

  • Model images are merged along with the parent model line. If the model line is merged, the images are used in the new database, too.

  • Group model records are duplicates if they have the same names.

    Example:

    Rules for duplicate group model records

    Source	Name	Description	Duplicate?	Result
    1	101	Office 1	-	The first source record is moved to the target database.
    2	101	Office 2	Yes	Replaces record.
    3	102	Office 3	No	Adds record.

  • Non-group model records are duplicates if they have the same names and descriptions.

    Example:

    Rules for non-group model records

    Source	Name	Description	Duplicate?	Result
    1	105	Garage	-	This first source record is moved to the target database.
    2	105	Garage	Yes	Replaces record
    3	105	Garage 1	No	Adds record after renaming the Model name
    4	106	Garage	No	Add record

  • If non-group model records have duplicate names, the model that is being merged is renamed using the next available unique name in the target database.

    Example:

    Renaming duplicate non-group model records

    Source	Name	Description	Action	Target (after merge)
    1	400	Pool	This first source record is moved to the target database	400 Pool
    2	400	Pool A	Adds record after renaming the duplicate name
    3	400	Pool A	Address record because even though the name and description are duplicates, it is a non-group record. The name is renamed when it is merged.	4002 Pool A

  • If a group model record and a non-group model record have duplicate names, the non-group model record is renamed during the merge.

    For example, if the duplicate non-group record is in the source database, it is merged and renamed using the next available unique name in the target database. If the duplicate non-group record is already in the target database, it is renamed using the next available unique name before the source group model record is merged.

    Example:

    Renaming group and non-group models with duplicate names

    Source	Name	Description	Group?	Action	Target (after merge)
    1	400	Pool	No	This first source record is moved to the target database	4001 Pool *
    2	400	Pool A	Yes	Adds record after renaming the non-group duplicate name already in the target database	400 Pool A
    3	400	Pool A	No	Adds record because even though the name and description are duplicates, it is a non-group record. The name is renamed when it is merged.	4001 Pool A

    * This record is renamed from 400 to 4001 because of the group and non-group duplicate name rule.

    Merge steps:

    1. Source 1: The 400 Pool record is the first record to be merged and is moved to the target database.

    2. Source 2: Name 400 of the 400 Pool A record is a duplicate. According to the merge model rules, the non-group record 400 Pool in the target database is renamed when the source 400 Pool A record is merged.

    3. Source 3: Name 400 of record 400 Pool A is a duplicate name and is a non-group record. Therefore, when it is merged, it is renamed to 4002, which is the next available unique name in the target database.

    Renamed models are identified as such in the log file.

• Phases

  Phases are duplicates if they have the same phase code.

  A non-group phase always takes precedence over a group phase with the same code.

  Example:  

  Order of precedence for phases

  Source	Code	Group?	Result in new database
  1	5000.00	Yes	Adds group phase
  2	5000.00	No	Replaces existing group phase with this phase
  3	5000.00	Yes	Ignores group phase

  Group phases that are ignored (skipped) because they match non-group phases are identified in the log file.

• Rate tables

  Rate tables are duplicates if they have the same name, description, type, detail counts; for each detail, the same crew resource name, benefit number, unit name and rate, column heading counts; and for each column heading, the same the display position, benefit number, heading, and percent setting.

  If only the names match, the merge process renames the rate table before adding it to the new database. The new name is the original name with a numeral at the end (characters are removed from the right if necessary). For example: Owned Equip becomes Owned Equip1.

  Renamed rate tables are identified as such in the log file.

• Resources

  Crew resources are duplicates if they have the same name, description, and type (e.g., both are labor or both are equipment).

  If only the names match, the merge process renames the resource before adding it to the new database. The new name is the original name with a numeral at the end (characters are removed from the right if necessary). For example: Electrician becomes Electrician1.

  After renaming resources, the merge process updates all references to those resources in the new database.

  Renamed crew resources are identified in the log file.

• Subcategories

  Subcategories are duplicates if they have the same name.

• Totals page template

  The template names are matched.

• Units

  Units are duplicates if they have the same name (including capitalization). For example, DAY, Day, and day are not matching units.

• User field names

  Only the values from the first database are merged.

• Variables

  Variables are duplicates if they have the same name (including capitalization).

• WBS codes

  WBS codes are duplicates if they have the same name.

  When you are replacing duplicates, Item-type WBS codes take precedence, followed by Takeoff-type and Detail-type, respectively. The WBS code in the new database retains the greater size.

  Example:  

  Order of precedence for WBS codes with duplicate names

  Source	WBS in source databases	WBS in new database
  1	WBS1 (Detail, size=15)	WBS1 (Detail, size=15)
  2	WBS1 (Item, size=15)	WBS1 (Item, size=15)
  3	WBS1 (Takeoff, size=20)	WBS1 (Item, size=20)

  The merge process adds WBS codes to the new database based on the type and the selection order of the source databases. When the new database reaches the limit of 40 WBS codes, the merge process ignores any remaining WBS codes in the source databases.

  If the position of a WBS code changes, the merge process updates all references to that record in the new database.

  The log file identifies:

  • WBS codes that could not be merged because there no WBS index.
  • WBS codes whose index changed.
  • WBS codes that were ignored because of the type precedence rules.

• WBS values

  WBS values are duplicates if they have the same WBS code and WBS value.

  If there is no matching WBS code in the new database, the merge process ignores the WBS value.