Obsydian Model Integrity Check Introduction Obsydian 3.0 will store group models in a third-party database management system. Existing 2.5 and 2.51 group models will need to go through an upgrade process in order to be used with Obsydian 3.0. Obsydian 2.51 includes an option that enables you to run an integrity check on your 2.51 model. This check can reveal problems that may prevent your model upgrading to 3.0. The problem relates to objects with duplicate surrogates. Depending on the particular situation, duplicate surrogates can exist in a 2.51 model without actually causing any problems. However, they will cause problems in the more robust 3.0 group model environment: the 3.0 upgrade fails with a primary key constraint violation. We recommend that you run the integrity check on all of your group models prior to the 3.0 upgrade. Duplicate surrogates are most likely to occur in older group models created prior to version 2.0 of Obsydian. Nevertheless, we recommend that you run the check with newer models as well as it may find other potential problems. Running the Load Checks report To check your model integrity, you need to run the Load Checks report. You do this by changing a setting in the OBSYDIAN.INI file. Note: This option is available in earlier versions of Obsydian. However, the Load Checks report has been improved for Obsydian 2.51 so it is recommended that you only follow this procedure with 2.51. 1.Create a new local model and perform a full extract of all objects and triples. In certain circumstances, the loading of the local model will flag duplicate triples as deleted. To check for this, look at the local model information panel - the 'Information' item on the 'File' menu. If the model is reported as being changed, log in to the group model, perform an update, and continue with the next step. 2.Save the local model, clear the Message Log and close Obsydian. 3.Before starting Obsydian, search for the 'Load checks' line in the [Options] section of OBSYDIAN.INI and change the entry to 2: Load checks=2 4.Start Obsydian and open the local model you created in step 1. 5.Messages are sent to the message log, reporting on various conditions found in the model. Reported conditions The following conditions are reported by the Load Checks report. Only one (GNL1519) may cause the 3.0 upgrade process to fail. Obsydian tolerates the others since they can occur during the normal process of building models. However, they should be resolved to ensure that your model behaves in the way you expect it to. Message GNL1519 Objects 'System: Character'(Active) and 'Variable: System'(Deleted) have the same internal surrogate 1593846769 Cause Action Two objects in the model have the same internal surrogate number. This will be reported even when one of the objects has been deleted. Check if both of the objects concerned are active and are of the same type. If so, this condition will cause the upgrade process to fail. You need to delete and re-create one of the objects. Delete the object that will cause least disruption to your model. If you are not sure which to choose, contact your local product support center for advice. If either object is deleted, or they are of different types, you can ignore this message. Message GNL1574 Name 'Triple: Agent Number (nk)/FLD length NBR/3' duplicated for internal surrogates 637551111 and 637606890 Cause Action A triple has been duplicated in your model. You will normally see this message twice for the same triple, once for each occurrence. This can be caused by more than one developer asserting the same property to an object, and then both update the group model. Locate the triples in the Model Editor and delete one of them. This condition will not cause any problems during model upgrade but may cause certain objects to fail generation. Message GNL1575 Cardinality error for 'Triple: &Saved Index/FLD edited by LBL/&Saved Index.ScrOutput3' and 'Triple: &Saved Index/FLD edited by LBL/&Saved Index.Output' Cause Action An object has two triples for the same verb, although the verb can only be specified once. This can be caused by more than one developer asserting the same property to an object, and both update the group model. Locate the triples in the Model Editor and delete one of them. This condition will not cause any problems during model upgrade but may cause certain objects to fail generation. After the model has been modified, you should save it, then close and open it. This will run the Load Checks report again. Once you are satisfied that you have eliminated all significant messages, update the group model. This process can be run as many times as you like, but should be run at least once, prior to upgrading your model to Version 3.0. If you have any questions, please contact your local Product Support center.