Data Integrity Checking

This is the Data Integrity Checking (DICE) tool supplied as part of the Admin module.

Its purpose is to provide a report on the base product Dabacon databases that informs the administrator if there are any issues with the database that require extra attention. In addition, you can also run it in a "patch" mode that will actually facilitate a repair on the database.

It is recommended that a full Dice report it is run as a matter of routine daily on all databases in the project. This includes the full extract family and secondary databases if AVEVA Global is in use.

Foreign projects, such as a centralized Catalogue, should also be DICE checked, although the frequency should not need to be so frequent if they are not being updated on a daily basis. Often this is done as a scheduled batch routine during no working periods.

However, if the project is in a period of intense activity and the window for running bulk processes for reports, drawings, material take-off is small, it can be run with users and batch processes continuing to run on the model.

Having produced the report it is imperative that it is closely scanned for issues of concern and then action taken to address them. Ideally, the Administrator should take action to remove all errors and warnings; however some warnings can be deemed to be acceptable and of no risk to the healthy running of the project, for example, Element =18585/38329 Warning- Attribute TREF contains invalid ref =18585/74770.

This error will also be highlighted to the normal users as they check their designs so it will be picked up there. However, if the identical reference numbers in these messages recur the Administrator should follow up with the last user to access the element (info in session data) to make sure it is cleared.

The Fatal Errors listed in a DICE report are usually ones that need immediate attention and action to repair the database will be needed. Nevertheless, on occasion the error can either be tolerated for a period as it is not truly critical, or may have been wrongly categorized as Fatal and constitutes only a warning , for example, Error in level 2 NAME table, session no. 10469, page no. 42385 - incorrect value of first key on lower level page no. 42386 (extract 1).

While AVEVA provide analysis of each error message outlining how it should be addressed, the nature of an individual project set-up can make the method on how they should be addressed variable. Therefore it is recommended that as the Administrator becomes familiar with the action needed to address each warning or error it is documented and recorded in project work instructions.

Certain database errors can be fixed by running Dice again against the problem database, this time in "patch" mode to repair the fix. Two typical examples are:

Child extract 12 not listed on header page

Element SBFITTING /SBFIT99 needs clearing from mainlist in header extract

This should normally be done when there is no Write access to the database. Even though the Dice report will report the problem cleared, it may be a good idea to rerun a Dice full check on the repaired db with "patch" mode disable to be 100% sure the problem is cured.

Other database errors can only be fixed by a Reconfiguration of the database. For example:

Element =35021/13323 has an inconsistent entry in the name table. Name

exists on the element but is not in the name table

itself. Thus the element can not be navigated to by name Please reconfigure this DB to resolve the problem

This work should be done when there are no Read or Write access to the database, but to avoid a complete project shutdown it is possible to remove the problem DB from all MDB’s do the repair and then replace it. Because of the additional complexity this may involve, looking for a window in the project workload is normally the preferred choice.

Two or three days before a phase of major deliverable production it is recommended to be especially diligent in Dice checking to make sure that all databases are in good shape and reduce the risk of an interruption in the bulk process.

If a user reports an unusual problem with part of the project data, such as a Dabacon crash, the first step should always be to perform a Dice check on the database(s) involved. If the report shows issues that cannot be repaired by patching or reconfiguration then the Dice report should be sent immediately to AVEVA support.

If after repairing the database the database is OK for a few days and then Dice reports errors again then this may indicate a deeper issue and the Dice report together with any background information on circumstances that are common to the error occurring e.g. same users, same UI menu etc. should be reported to AVEVA support who may then request that the databases be sent in for fuller investigation.