Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Engineering

Data Integrity Checking

  • Last UpdatedOct 15, 2025
  • 3 minute read

The Data Integrity Checker (DICE) scans the internal structure of a database and detects any errors. It performs the following checks:

  • Ensures the data hierarchy is intact and all lists contain the correct members.

  • Confirms all element names are correctly stored and accessible.

  • Checks that references to other databases are valid. If not, DICE outputs a warning. This is typically due to a deleted database.

If DICE finds an error in any of these checks, it displays a message on your screen or writes it to a named ASCII file in your working directory.

Note: For more information regarding databases, see Database Management System. As DICE checks the internal structure of a database, it may be helpful to read this first.

DICE can be run in one of two ways:

  • From within AVEVA Administration.

    This is the most common way to run a DICE check.

  • In a stand-alone program.

    This is typically used when the System database is corrupted and the administrator cannot open AVEVA Administration. In this situation, DICE can be run without entering a project by targeting the database files. See Stand-Alone DICE for more information.

Macros can be used to automate DICE checks. A macro is a text-based script that contains a sequence of commands. For information on how to create a macro, see Create Script.

The commands used to write DICE macros, or to run DICE as a stand-alone program, are described in the Administrator Command Reference Manual. Some commands are specific to Administration mode, others are specific to stand-alone mode, and some work in both. DICE detects which mode it is operating in and rejects any inappropriate commands.

Common Causes of Database Corruption

Corruption may result from:

  • An error in the network, resulting in loss or non-arrival of data.

  • Improper copying of databases, leading to truncation.

  • Insufficient disk space or storage quota during database updates.

  • Deletion of a Database (DB) referenced by another.

  • Reconfiguration of a DB without a corresponding update of all DBs which have references pointing into it.

  • Undetected faults in the AVEVA base products Database Management software (see Database Management System).

It is recommended to run DICE to check all of the project databases in a live project on a regular and recurring basis. This way, any corruption that might occur can be corrected promptly. In general, it is far easier to repair a database shortly after corruption occurs than to allow a project to continue running with a compromised database for an extended period.

The frequency of DICE checks is at the discretion of the Administrator, and depends on the number of users and the amount of activity in the project. DICE can be run daily, weekly, or monthly depending on project needs and administrator workload. DICE is optimized for speed and minimal resource consumption, making it practical to proactively check the whole project database frequently, rather than in response to an issue such as a system failure.

You can safely run a DICE check without patch while users are active in the project without disrupting operations or performance. Because a full project scan can be time-consuming, administrators can set up a macro to schedule DICE to run overnight as an unattended task. System Administrators typically create and maintain a set of standard macros for running regular DICE checks.

Running a check overnight produces a report that is available for review the following day. Typically, the Administrator searches the report for the term FATAL, as fatal structural issues in the database must be addressed immediately. The following flow chart shows how to address this.

TitleResults for “How to create a CRG?”Also Available in