Here you will find an explanation and best practices for solving Data inconsistency related synchronization errors.
Inconsistent data refers to data that contains discrepancies or errors within a dataset. These inconsistencies can arise for various reasons and can make the data unreliable or difficult to work with.
The purpose of an alert message is to convey important information.
Error message: "An element in <File name> is re-using GlobalID <GUID>. The last seen element with this GlobalID will be present in the iModel."
Issue:
Visual fidelity issues in iModel such as missing element/s.
Cause:
The source application generated the IFC file that has an element(s) with the same Global ID.
Solution:
Error message: "Units of type MASSDENSITYUNIT not defined"
Issue:
Missing information in the IFC file MASS DENSITY UNIT in the iModel viewer.
Cause:
MASS DENSITY UNIT values were incorrectly exported to the IFC file from the design application and can not be converted to the iModel
Solution:
Since IFC is an open standard for the exchange of building information models (BIM) data and not a design file format, it cannot be updated directly. Updating the units in the IFC file will typically require making the appropriate changes in the design application so that the MASS DENSITY UNIT will be updated the next time an IFC file is generated from the design application. Once the unit is correctly reflected in the IFC file, it can be resynchronized into the iModel.
Error message: "Cannot process geometry for RVM Component: <ComponentName>"
Issue:
Connector failed to process geometry of the given component.
Cause:
Inconsistent geometry data for the component, for example a radius value of 0 for CYLINDER/CTORUS etc.
Solution:
Verify the geometry data for the component in the source application. Once the geometry data is correctled, the source file can be resynchronized into the iModel.
The purpose of an alert message is to convey important information.
Fatal Error message: File <> has <> as its document ID from the dgn file. However the attached data is from a different data source.
Issue:
The connector reports this issue during an update, while checking for deleted documents, when a reference attachment's document identity is inconsistent — the document identity recorded in the DGN file does not match the document that the data source now associates with that file. Because of this ambiguity, the connector cannot safely delete or reconcile the stale reference.
This issue is raised when the file is present and not deleted, but its attached data comes from a different data source. It is reported as Fatal, so the update stops.
The affected reference/attachment is not deleted or reconciled; it remains as a potentially stale reference in the iModel until the mismatch is resolved. The closely related Error-level issue DgnV8_0209 and the Fatal issue DgnV8_0141 are reported for related conditions found during the same step.
Cause:
This issue is reported when:
Common causes:
Solution:
Reconcile the reference's document identity:
Re-run the synchronization:
Best Practices:
Error message: File <> has <> as its documentId from the dgn file. However the attachment data from the data source is <>.
Issue:
The connector reports this issue during an update, while checking for deleted documents, when a reference attachment's document identity is inconsistent — the document identity recorded in the DGN file does not match the document that the data source now associates with that file. Because of this ambiguity, the connector cannot safely delete or reconcile the stale reference. Unlike the Fatal cases, this is reported as an Error and the update continues.
This issue is raised for two related conditions:
The affected reference/attachment is not deleted or reconciled; it remains as a potentially stale reference in the iModel until the mismatch is resolved.
Cause:
This issue is reported when:
Common causes:
Solution:
Reconcile the reference's document identity:
Re-run synchronization:
Best Practices:
Duplicated data can be introduced in different scenarios and can cause duplicated data to appear in the iModel, which is not desired.
Error message: File <File name> has <File path> as its documentId from the dgn file. However, the attachment data from the data source is <File ID>.
Issue:
Visual fidelity issues such as graphical and properties duplication.
Cause:
References ID had changed due to reference file migration to a different data source.
Solution:
Run a Scan References on the master file and then restart the synchronization. If the duplicate issues cannot be solved, please contact Bentley support to further diagnose this kind of error: https://bentleysystems.service-now.com/csp
Read more about why reference scanning is important.
Error message: "Duplicate models found MasterSubject:<File name> MissingInputFile: <File path>.
Issue:
Visual fidelity issues in the model such as duplicated graphical information and properties.
Cause:
Error message: Overlapping geometry detected between File, Model <> and File, Model <>.
Issue:
Overlapping geometry between 2 different models has been detected. This check exists to help detect when the same model has been referenced from two or more different models and can result in the exact same model being synchronized twice. However, there are also cases where some of the overlapping geometry is not due to a duplicate model, but overlapping geometry.
Cause:
Duplicate models are being synchronized or there is overlapping geometry from different models.
Solution:
After the iModel has been synchronized, view the iModel and turn off all models except for the referenced models. Then alternate turning one of the two remaining models on and off to see if they are duplicated and or have overlapping geometry. If the models appear to be the same content, then you should update your iModel connections to resolve the duplication. If there is overlapping geometry and it is expected as the 2 models are different, but have intentionally added overlapping geometry, then you can ignore this issue.
Error message:
One of the following errors will be mentioned:
Unable to delete the duplicated Model, File, Model <> and File, Model <> with ID <> where overlapping geometry was detected. Error <>.
Unable to delete the duplicated Model, File, Model <> and File, Model <> with ID <> where overlapping geometry was detected where overlapping geometry was detected after abandoning changes. Error <>.
Issue:
The un-mapping of a duplicated model has failed. During the synchronization, it was determined that there was overlapping geometry between two models. To prevent duplicate data within the iModel. it was attempted to un-map the model currently being synchronized, but the un-map failed.
Cause:
There was a failure in the un-mapping of an instance where overlapping geometry between models was detected.
Solution:
Please contact Bentley Support and mention this error number when submitting the service case so Bentley can investigate the cause of the error.
Warning message:
It was determined that the models File, Model <> and File, Model <> with ID <> has overlapping geometry and the model was automatically un-mapped by the connector to prevent duplicates.
Issue:
When the iModel Connector determines that there is overlapping geometry between models, it will automatically un-map the newly added model to prevent duplicated geometry within the iModel. Normally, this is just a warning that you should check you iModel Connections to ensure that you have not configured the connections to introduce duplicates. However, there could be instances where the overlapping geometry is not caused by duplicated models, but by the intentional overlapping of geometry and in this case deleting the model is incorrect. In this case, please submit a service case as mentioned below and the un-mapping in this case can be turned off for this iModel.
Cause:
It was determined that there is overlapping geometry between geometry from a model that already exists in thei iModel and the model currently being synchronized. In this condition, the default behaviour is to unmap the overlapping model in the current synchronization.
Solution:
Please check your iModel connections to ensure that they are not configured to bring in duplicate models. If you feel that the overlapping model should not have been unmapped, please contact Bentley Support for assistance and the automatic un-mapping can be disabled for your model.
Warning message: Duplicate component name at line #n.
Issue:
The attribute file has multiple components with the same name. When this happens, the connector combines them together and values for repeated properties are updated as per the latest component set.
Cause:
The file may contain duplicate components, or there may have been an issue when exporting the .att file from the source application.
Solution:
Rename the duplicate component in source software and then re-export and resynchronize.
Error message: Update of element [Element Name] [Model Name]failed; element (and any children) will be deleted. Status code: [error code]
Issue:
The connector reports this error when it tries to update an existing element in the iModel and the update does not succeed. Because the element could not be safely updated, the connector may remove the element and any child elements to avoid leaving inconsistent or broken data behind.
Example:
Element: [Element Name]
Model: [Model Name]
Status code: [error code]
This condition can happen when the target model contains stale or conflicting data, when another process is editing the same element, or when the database operation fails while saving the updated element.
Cause:
The synchronization attempts to update an existing element so it matches the latest source content. If that update fails, the connector treats the element as unsafe and may delete it, along with its children, to prevent invalid or an inconsistent model state.
This issue typically occurs when:
Because the update did not complete successfully, the connector chooses to remove the element rather than leave the model in a partially updated state.
Solution:
If the element is no longer needed or is a stale duplicate, removing the redundant content may also resolve the issue.
Best Practices:
Warning message: The connector reports a duplicate-code warning when updating an element whose newly computed Code collides with a Code that is already in use by another element in the same iModel. The message identifies the duplicate code value, the existing element that already owns it, its model, and the code the connector will keep.
Example (conceptual):
Duplicate element code 'PUMP-001' detected while updating element 0x30000000123 in model 'Structural'. Keeping existing code 'PUMP-001'.
Issue: During an update, the connector recomputes each element's Code (its unique business key/identifier within its scope). If the new Code the connector wants to assign is already taken by a different element, the update would violate the iModel's uniqueness constraint on Codes. Instead of failing the element, the connector:
Effect: the element is updated successfully, but it does not receive the newly computed Code — it retains its previous Code. This can result in:
Conversion continues normally because this is a Warning, not a fatal error.
Cause: Codes in an iModel must be unique within their scope. This issue arises when the connector computes a Code for the element being updated that matches a Code already assigned to another element. Common causes include:
Solution:
Best Practices:
Error message:
<Property Name> property value <number> <unit symbol> of <unit name> dimension is ignored due to missing persistence units; perhaps the schema in the Revit model is damaged. Please contact Bentley support.
<Property Name> property value <number> <unit symbol> is ignored due to missing persistence units; perhaps the schema in the Revit model is damaged. Please contact Bentley support.
Issue:
The unit for a property can't be placed in the iModel.
Cause:
The property units are unknown in this case.
Solution:
Please contact Bentley support mentioning this warning and they will help analyze the problem and suggest a fix.
Error message: "Invalid IfcDirection <>, expected (minimal) dimension"
Issue:
An IfcDirection entity in the IFC model does not have the required number of components (for example, fewer than 3 components for 3D geometry). This makes the direction invalid and prevents correct geometry interpretation.
Cause:
Solution:
Warning message: "IFCPOLYLOOP contains identical points. Geometry may not be generated correctly."
Issue:
The IFC model contains one or more IFCPOLYLOOP entities where all (or multiple) loop points are identical. This produces a degenerate loop, so the connector may not be able to generate valid geometry (for example, a polygon requires at least three distinct points).
Cause:
How to identify the affected element
Solution:
Warning message: Could not find definition or name for line style <> in file <>
Issue:
During synchronization of the DGN source file, the connector encountered an element that references a line style by number, but no line style definition and no line style name could be found for that number in the file. The converter emits:
This is a Warning, the conversion will continue. The affected element is converted without the referenced custom line style; it falls back to a default/solid line style, so its appearance may differ from the source.
Cause:
Elements in a DGN file store a line style as a numeric ID. This warning occurs when the connector is unable to resolve neither a definition nor even a name for the given number. Common reasons:
(Note the related messages: DgnV8_0049 is raised when a name is found but the definition is missing; DgnV8_0046 when the component of a named style cannot be loaded. DgnV8_0048 is the case where nothing at all can be resolved.)
Solution:
Warning message: Could not find definition for line style [LineStyleName]. Some elements may not display properly.
Issue:
The connector reports the following warning message when processing DGN elements that reference a custom line style whose definition cannot be found:
Could not find definition for line style [centerline]. Some elements may not display properly.
The MicroStation system line style map.
The active DGN file.
Referenced resource files (.RSC).
Referenced DGN files.
Incorrect line appearance.
Missing custom line patterns.
Elements displayed with continuous/default styles.
Visual differences between the source design file and the resulting iModel.
Cause:
The synchronization process imports custom line style definitions before geometry conversion.
This warning occurs when a line style referenced by an element cannot be resolved from the available source data.
Common causes include:
Based on the converter code, the warning is only generated when:
Solution:
Identify the Missing Line Style:
Review the synchronization log and note the line style name reported in the warning message, for example:
pa_centerline
Verify the Line Style Exists in the Source Environment:
Open the source DGN in MicroStation and confirm that the reported line style can be displayed correctly.
Check Resource Files (.RSC):
Ensure all custom line style resource files used by the project are available and included in the synchronization dataset.
Review Referenced Files:
Verify that all DGN references containing custom line style definitions are present and accessible.
Validate Workspace Configuration:
Confirm that the workspace and workset used during synchronization contain the same configuration variables and resource locations used by the authoring environment.
Repair Missing Definitions:
If the line style no longer exists:
Replace Obsolete Line Styles:
If the style is no longer required:
Re-Synchronize and Validate:
After restoring the missing definitions:
Best Practices:
Warning message: DgnModel <model> was previously imported with a different DGN->iModel transform. Check GCS and/or reference attachment. - <file>
Issue:
While converting/updating a DGN dataset, the iModel connector found that a model it is about to import was already imported previously, but with a different DGN→iModel placement transform.
This is a Warning and the conversion will continue. Because the model's current transform does not match the one it was first imported with, the converter does not reuse the existing mapping for that transform; the geometry may be placed differently than expected, or effectively duplicated at a new location.
Cause:
When a model is imported, the connector records the transform that maps the source DGN coordinates into the iModel spatial coordinate system, keyed to that model. On a later pass (or when the same model is reached through another reference path), the converter compares the current transform against the stored one. DgnV8_0080 is raised when a matching model exists but none of the stored transforms match the current one within tolerance. The typical reasons are:
Solution:
Warning message: "Datatype mismatch found in property: <> from the current IFC file"
Issue:
The connector detected that the same logical property is defined with different datatypes in the IFC file. This can cause inconsistency and potential data loss during mapping and synchronization.
Cause:
Solution:
Warning message: "Multiple datatypes 'DataTypeName' are defined for property 'Property Name' in the property set 'Property Set Name' resulting in data loss. This inconsistency needs to be corrected by the source application for this property to be consistently synchronized."
Issue:
Data loss is observed for the element with the problematic property in the iModel (e.g. Property 'NEL_Diameter' shows an empty value in the properties section in the iModel).
Cause:
Solution:
The inconsistency of datatypes for the problematic property should be fixed in the IFC File. Since IFC is an open standard for the exchange of building information models (BIM) data, it cannot be updated directly. The inconsistency in the IFC file should be corrected in the design application so that there will be no missing data for the property in the iModel. Once the IFC file has been corrected and generated from the design application, resynchronize the IFC file to the iModel. This should solve any issues with the missing data for the problematic property.
How to fix the IFC file:
Warning message: "RVM data was used as input, but no RefId type of value was found for [xx] element(s)."
Issue:
When bringing AVEVA E3D data that has been exported into the RVM format into the iTwin platform via the Navisworks (NWD) connector, you might encounter the Nwd_0014 warning: "RVM data was used as input, but no RefId type of value was found."
While it is easy to dismiss as a minor property warning, missing RefId (Reference Identifier) data fundamentally impacts your iModel's integrity, as the RefId is the unique key linking the iModel element back to the original authoring tool. Without it, the connector loses its ability to track elements across synchronizations.
Missing RefId in the exported NWD file can cause a few issues:
The following are accepted values for RefId, these values are case sensitive.
REF
REF-NO
REFNO
RefId
RefNo
:RefId
:RefNo
Ref-Id
Ref-No
:Ref-Id
:Ref-No
PDMSRef
:PDMSRef
Cause:
Solution:
Re-generate the NWD file with the following properties and synchronize to the iModel: