XML Import is done in the following steps:

1. Loading of XML files.
2. The first parsing of XML data.
3. Matching of the objects and references with the target configuration:
   • matching of the imported objects with the target configuration
   • ID is assigned to new objects (insert), if the ID reservation failed or ID was zero
   • matching of the object references with the target configuration
   • parent consistency check of the changed objects (update), but the change is permitted only for the I/O tags, Event, Database or Table
   • matching of the column references with the target configuration
4. Reading of the binary files.
5. The second parsing of XML data.
6. XML data import.

XML data parsing

Each XML file together with the proper binary files represents the object configuration that is to be imported.

The conditions of successful parsing:

• XML file structure must be correct
• each object reference <HOBJ_REF> in <REFERENCES> section must have:
  • filled name <name>
  • unique name <name> and <uid> (if it is filled) within this section
• each column reference <COL_REF> in <REFERENCES> section must have:  
  • filled name <col_name>
  • unique name <col_name> and <col_idx> (if it is filled) within this section
  • <col_idx> must not acquire the value higher than MAX_VALID_COL_IDX = 7777
• the structure <tObjItemData> must be listed as the first in <CFGRECORDS> section
  • name <Name> of structure must be filled
  • if the object in references refers to itself, its name must match with uid

If object or column reference is found while parsing <CFGRECORDS> section (it was not found according to name in prepared references from <REFERENCES> section), it will be added automatically into <REFERENCES> section. It means, the references from <REFERENCES> section are just a sort of some rule that is primary taken into consideration but the import may be done also without <REFERENCES> section.
This action is followed by a check whether all the objects (as individual elements) were changed from XML to the structures in memory. It only involves the check of objects (whether they are correct or not) regardless of their membership in the particular configuration.

Matching of the imported objects with target configuration

The principle of object matching is shown on the flowchart of object matching.

An important element at matching is uuid in TObjItemData structure.
The second important element is Name in TObjItemData structure.

Warnings that may occur at matching:

• the object is being updated via NAME after the entered UID of object was not found (see 4. and 5. example in the flowchart)
• the object is being updated and the value type of object is different from the value type of object in target configuration
• the object is being inserted and the entered ID of object was not reserved in target configuration

Errors that may occur at matching:

• value of UID or NAME is the same as value of another imported object
• object intended for import relates to object that just has been deleted from target configuration
• loads such the UID from the target configuration that already exists among the imported objects (see 2. and 4. example in picture)
• object is being renamed but this NAME has another object in the target configuration (see 7. example in picture)
• import of new object with name that already belongs to other object in the target configuration (see 6. example in picture)
• object intended for update is of different type than object in the target configuration
• parent object of the imported object is not set
• parent object of the object intended for update is different than the parent object of the imported object (except the object I/O tag, Event, Database or Table because they allow the changes)

Matching of the object references with target configuration

The principle of object references matching is shown on the flowchart of object references matching.

The important element at matching is uid in HOBJ_REF structure.
The second important element is name in HOBJ_REF structure.
If the parameter IGNR_REFS is checked, the matching may be executed only through the second element.

Warnings that may occur at matching:

• name, type, or value type of object is different in object reference than in the object which refers to
• object of reference is searched via NAME after the reference could not be connected via UID (only if import parameter UID_STRICT = OFF)

Errors that may occur at matching:

• the object which the object reference refers to can not be found

Matching of the column references with target configuration

The principle of column references matching is shown on the flowchart of the column references matching.

The important element at matching is col_idx in COL_REF structure.
The second important element is col_name in COL_REF structure.
If the parameter IGNR_REFS is checked, the matching may be executed only through the second element.

Warnings that may occur at matching:

• name or value type of column is different in column reference than in the column that refers to

Errors that may occur at matching:

• the column, to which the column reference refers, can not be found