4. TADB/PRT Backing File Synchronization and Recovery

Result: If errors are found, they are reported using the same, but greatly extended TADB error message.

Synchronization and recovery overview

The PRT Collector manages discrepancies or corruption in the PRT backing files as follows.

• Synchronize data

When the project is not running a user can have the PRT Collector synchronize PRT and TADB.

During synchronization PRT data overwrites TADB data in most cases.

Note: When items in TADB that are assigned to regions in TADB, but are not in PRT, by default they will be archived unless archiving is not indicated; in that case the item will be made regionless.

• Recover data

When a project starts PRT Collector validates the data between PRT backing files and TADB.

If PRT backing files are corrupt the PRT Collector will:

Differential Report Timestamps

The PRT_TADB_Diff report displays the last modified timestamps in both TADB and PRT for the representation of an item.

• Knowing the last modified times can help determine which version of data is true, if there are differences between TADB and PRT for an item.
• Because the timestamps will most often be different, if they are the only difference between PRT and TADB for an item, that item will not be listed in the report.

Synchronization report and implementation steps

Step 1	Create/Open PRT vs. TADB Validation Reports
Step 2	Review and Copy Report Data
Step 3	Synchronize PRT Backing Files and TADB

Backing File Recovery when there are Decreased in PRT Configuration Components

When the PRT configuration changes after items have been logged to the database involve reductions, e.g. fewer regions, fewer locations, fewer items in a location, recovery attempts to:

• Maintain the item sequence.
• Maintain item associations.
• When warranted, move items to the next location or region.
• Report all changes and issues in the Status Log.

The following examples portray two possible situations.

Example 1

REGION1's capacity initially is 200.

The capacity is reduced to 150.

Recovering items from the database starts at Location 1.

Items are recovered from 1-150.

At 150, the revised capacity is full; there is no more room for items.

Item 151 is not recovered.

An initial warning and failure are logged to the status log that:

• Item count %d <200> exceeds Item capacity %d<150> for region <REGION1>.
• Location %d<151> for Item %s<widgets> exceeds region <REGION1> locations %d<150>.

Reports about all items over 151 are also logged to the Status Log.

Note: The recovery maintains the initial integrity of items/location. If the location allows 2 items and only 1 item is in the location at the time of recovery, the location will continue to have only 1 item.

Example 2

The location capacity in REGION1 is initially is 3 items.

The capacity is reduced to 2 items.

If the database contains 3 items in a location recovery will attempt to fulfill three requirements.

• Maintain the item sequence.
• Maintain item associations.
• Reduce the number of items in the location to 2 or 1.

The recovery starts with the first item in the location.

The following table displays how database items in locations that previously allowed 3 items are allocated during recovery.

Location	Database Items	Recovered Items
1	1A, 1B, 1C	1A, 1B
2	2A, 2B, 2C	1C
3	3A, 3B, 3C	2A, 2B
4	4A, 4B	2C
5	5A, 5B, 5C	3A, 3B
6	6A, 6B	3C

• For each instance that an item is re-assigned to the next location a report is logged in the Status Log.

Adjusted %s<1C> location from %d<1> to %d<2> during recovery. Updating TADB to match.

• For each instance that there is an attempt to re-assign an item and the region/location capacity is exceeded, a report is logged in the Status Log.

Adjusted location %d<7> from %d<4> for %s<4A> exceeds %s<REGION1> %d<6> locations.

Failed recovery %s to %s at adjusted location %d, %d orig.

Where the message components are:

Failure to recover <item> to <region> at adjusted location <attempted location>, <database location>.