Repairing Errors

After errors have been identified, you can use the JADE Logical Repairer to assist in repairing the errors.

Although many errors can be repaired without your input, some situations require you to decide between alternative repairs. In addition, situations involving duplicate keys require you to write a script to repair the error.

For large production systems, it may not be realistic to take the system off-line for the length of time taken to certify and then repair the system. In this case, you can run the JADE Logical Certifier utility on a backed up database and run the repair process on the actual database as soon as it is practical to do so.

Even though the errors that are reported and the errors that are produced relate to the state of the database when the diagnostic tool was run, the repairs contain checks that specify conditions that must still apply for the repair to be performed.

It is important that no reorganization of the database has subsequently been performed, as the reorganization may invalidate the repairs.

The repair process is driven by the _logcert.fix file that is created when the JADE Logical Certifier utility is run. This file contains a list of repairs that need to be made and is in the following format.

FIXnnn: fixcommand param1 param2 ... [CHECK: checkexpression]

The optional CHECK part of the command contains conditions that must apply for the fix to be applied. You can use the FIXnnn number to relate the fixes to the report in the _logcert.err file. For details about the errors and repairs, see "Logical Certifier Errors and Repairs", later in this chapter.

The fixcommands that can be output to the _logcert.fix file are as follows.

null obj prop

This sets the prop reference on the obj object to null.
set obj prop refobj

This sets the prop property on the obj object to reference refobj.
nullKP obj prop or setKP obj prop refobj

This sets the prop reference on the obj object to null or reference refobj where the prop reference is part of a key path. Key maintenance is turned off when this repair is performed, to avoid problems with object not found errors that could result if key maintenance was performed.

A rebuild command to rebuild any collections where this reference was part of a key should also be generated, to update the keys.

Any nullKP and setKP command is performed before any rebuild command.
rebuild coll

As the coll collection contains references to objects that have been deleted or it has invalid keys, the collection is rebuilt.
add coll obj

This adds the obj object to the coll collection.
remove coll obj

This removes the obj object from the coll collection.
setBit obj subobj

This detects that subobj, a sub-object of obj, has been created but the creation bit of obj is not set so it sets the bit.
orphan oid

This detects collections whose parents no longer exist in any file in the database.
orphanBlock filename

This detects collection blocks whose parents no longer exist in any file in the database, both in user data files and user meta schema files.
delete obj

This deletes the obj object.
deleteInstances fileName className classNumber

This deletes the abstract class name and class number instance from the database map file.
mappingCount obj count

This resets the mapping count of the obj object to count.
fixSlobOrBlob obj prop

This repairs the incorrect length or edition of the parent object relative to the String Large Object (slob) or Binary Large Object (blob).
orphanSlobOrBlob imap

This detects String Large Objects (slobs) or Binary Large Objects (blobs) whose parents no longer exist in any file in the database, both in user data files and user meta schema files.

The JADE Logical Certifier utility decides which fix is appropriate, by treating the Manual side of an inverse reference as being correct.

Orphan blocks may be created when a dictionary with missing blocks is deleted by a delete or an orphan repair. If any unreachable blocks exist prior to the collection being deleted, they will not be reported as orphans until after the collection header is deleted. A message is logged to the Logical Certify repair.log file if a collection that contains missing blocks is deleted. Run the Logical Certifier again to determine whether any orphan collection blocks have been created.

As the correct repair cannot be determined for Manual/Automatic inverse references, the repair is output as three or more lines that are commented out, as shown in the following example.

//FIX1: Choose either first fix if man/auto reference Class1::prop1 acts
        as auto else following 1 line(s)
//FIX1: fixcommand1 ....
//FIX1: fixcommand2 ....

You should choose the first repair (fixcommand1) if Class1::prop1 should be treated as the automatic reference and the second repair (fixcommand2) if Class2::prop2 is the automatic side of the reference. To edit these, remove the two virgule, or forward slash, separators (//) that act as comments from the correct repair and then delete the other two lines.

When certifying meta data, fixes are provided for errors in the 98 category; for example:

FIX1: set 1291.67 schemaType 1281.185 CHECK: '1281.185'.asOid.getPropertyValue('properties').Object.Collection.includes ('1291.67'.asOid)

FIX1: delete 1281.794 CHECK: '1281.794'.asOid.Type.schema=null

Errors 88 and 99 are meta data errors for which no fix is provided, which is stated in the _logcert.err file.

After editing the _logcert.err file, you should run the repair by performing one of the following actions.

Access the standalone JADE Logical Certifier utility again and selecting Repair in the Operation combo box and then clicking the Repair button in the Jade Logical Certifier dialog to fix the errors in those schemas or classes.
Run the jadclient program with the following arguments.
```
jadclient path=database-path
          ini=c:\jade\system\jade.ini
          schema=RootSchema
          app=JadeLogicalCertifierNonGui
          server=SingleUser
          startAppParameters
          operation=repair
          logDir=log-file-disk-path
```
Running the jadclient program with these arguments, all of which you must specify, initiates a repair of all schemas in the database. To avoid possible inconsistencies and contention with running applications, the JADE Logical Certifier utility must be run in single user mode.

The logDir argument specifies the directory to which the log files are output (for example, logDir=c:\jade\system\diagnostics). An exception is raised if this directory does not exist or you do not specify a value. A progress output window is displayed as the classes are analyzed and instances validated.

The repair process uses your selected fixes in the _logcert.fix file and results in a _repair.log file containing the repairs that are made. Any errors that are encountered are logged in the _repair.err file and any repairs that cannot be performed are output to the _repair.fix file.

When the repair completes, the _repair.fix file is renamed _logcert.fix and the existing _logcert.fix file is renamed _logcertBackup.fix. This file contains any repairs that could not be actioned, including repairs that you did not edit and any repair that produced an exception.

Exceptions raised from repairs are output to the _repair.err file, which contains a log of the errors.

The most-likely exceptions that are raised are 1310 exceptions that result from duplicate keys being detected when the collection is rebuilt or an object is added to a collection. The most-likely exceptions raised from repairs are output in the following format.

rebuildDUPLICATE coll
addDUPLICATE coll obj

For other exceptions, the fix is output with ERROR appended to the fixcommand, as follows.

setERROR ...

In such cases, you must write a JADE script to correct the data.

A warning may be given if an add is performed to a collection and that object already exists. This can happen if a rebuild of a collection exposes an object that is hidden because of broken keys. You can ignore these warnings.

In addition, it is possible for the CHECK conditions associated with the repair to no longer apply, in which case a warning is given. This can occur because the database has changed since the JADE Logical Certifier utility was run or because of another repair. You can ignore these warnings.

Rerun the JADE Logical Certifier utility after the repair has been completed, to confirm that you have repaired all errors correctly.