4. TADB/PRT Backing File Synchronization and Recovery

About this task

  • Logical discrepancies between Tracker and TADB.
  • Synchronization and recovery overview.
  • Differential report timestamps.
  • Synchronization report and implementation steps.
  • Backing file recovery when there are decreases in PRT configuration components.

Logical Discrepancies between Tracker and TADB

Whenever an item is added to TADB or modified in TADB (which almost always is when an out of sync issue will occur):


  1. SQL Server returns all the data being stored for the saved item.
  2. PRT compares the values returned from the TADB to those in Tracker.
  3. PRT compares every field returned to its internal value and sends a descriptive error message to the same synchronization error handler that currently logs a message and raises an out of sync alarm.

    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:

  4. Delete the corrupt backing files.
  5. Create new blank backing files.
  6. Query the TADB database for the data needed to recover the backing files.
  7. Recover the data from the database.

    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.

    Note: If an unforeseen error occurs while recovering an item from the TADB, the following message is logged to the status log.

    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>.