The information in this article applies to:
This article discusses guidelines and procedures for restoring STI data from a backup. In the event that you have to restore from a backup, the information in this article can help you understand when to restore, what to restore, and what must be done before and after restoring to facilitate complete reconstruction of any data.
What Does it Mean to Back Up Your Data?
Running the Data File Integrity Check Before Backing Up
STI's Built-In Temporary Backup Utility
About Restoring Data from a Backup
When to Restore Data from a Backup
Before Restoring Data from a Backup
Which Systems Should Be Restored?
Integration Considerations when Restoring TABS III Data
Integration Considerations when Restoring PracticeMaster Data
Integration Considerations when Restoring APS Data
Integration Considerations when Restoring GLS Data
Integration Considerations when Restoring TAS Data
Reports to Run Before Restoring
Accounts Payable System Reports
Trust Accounting System Reports
After Restoring Data from a Backup
Backing up your STI data means making a complete electronic copy of all your valuable data files in a location separate from the directory where the data is normally stored. The purpose of regularly backing up your data is to ensure that valuable time and resources are not wasted recreating and redoing work in the event that data becomes corrupted or lost. The When to Restore section below lists some examples of circumstances in which a good, recent backup can save your firm time and money.
Before making a backup of your data, it is a good idea to run the Data File Integrity Check and Archive File Integrity Check programs to ensure that the backup will contain error-free data. A backup that contains critical errors or corruption would be of no use if you should have to restore. If the integrity check indicates errors, they must be resolved before making a backup.
It is strongly recommended that all firms have regular backup procedures in place to copy all STI data to some form of external backup media such as a backup tape, ZIP disk, or CD-ROM. Ideally, data should be backed up on a daily basis, and each complete backup should be retained for at least one week. Many firms use an automated backup system to copy all data to a tape backup every night after everyone has left for the day. Even with automatic systems, however, it is important to periodically check the status of the backups being made, to ensure that the backup system is functioning properly. STI Article R10456, "Testing Your Backup System", provides additional information about testing your regular backups.
Note: Do not overlook the importance of maintaining backups in a separate location in the event of theft, fire, flood, etc.
| Important: It is the responsibility of each firm to ensure that its backup procedures are adequate. STI is NOT responsible for determining what procedures should be in place and ensuring that they are implemented and maintained. |
In addition to making regular external backups, STI recommends that you take advantage of the built-in backup utility provided with all STI systems Version 10 and later (as well as with TABS III Version 9). Additional information regarding the use and function of the internal backup utility is available in STI Article R10278, "Troubleshooting the Built-In Backup Program".
Restoring data from a backup means copying all STI data files for the affected system(s) from a backup that was made earlier (when there were no problems), to the directory where your current data is stored. Restoring is usually considered a last resort, since the current data files for the affected system(s) will be overwritten by the data that was backed up. This means that any work that was done in the STI systems after the backup was made must be redone after restoring. For example, suppose your server crashes on Thursday and it becomes necessary to restore. If your last backup was made on Monday night, any transactions that were entered and any processes that were run in the affected systems on Tuesday, Wednesday, and Thursday must be re-entered after restoring. For this reason, it is strongly recommended that you have regular backup procedures in place to limit the amount of work that must be re-entered in the event that you have to restore.
Note: When restoring, you must restore ALL data files for a system. For example, even though you may need to restore TABS III data due to corruption in the Client file, you must restore ALL TABS III data files and not just the Client file. This is because STI data files contain information closely related to all other files for the same system. Likewise, integration between the STI systems must be considered when restoring data.
Because restoring from a backup is usually considered a last resort, it is important to know when to restore from a backup and when not to restore. It is also important to understand that there are some situations in which it may not be immediately obvious that you need to restore, but in which restoring is nevertheless required. There are certain processes in each STI system which, once begun, must complete without interruption, or serious data problems may result. The tables below list each function that prompts you to make a backup before proceeding. If any of these functions are interrupted (e.g., by a system crash, an improper shutdown, etc.), you must troubleshoot the cause of the interruption, restore from a backup, and run the process again before proceeding.
| PracticeMaster Processes |
Accounts Payable System Processes |
General Ledger System Processes |
Trust Accounting System Processes |
| Change Key Type | Change Key Length | Change Account Number Format | Change Key Type |
| Check In Briefcase | Clear Vendor Analysis Totals | Change Fiscal Year | Import Transactions |
| File Maintenance | Import Invoices | Month/Year-End Close-Out | Purge Trust Transactions |
| Process Timer Records | Post Checks | Post ASCII Data | Reindex Files |
| QuickBooks Integration | Post Recurring Entries | Post Great Plains Payroll Data | Rename Payee |
| Reindex Files | Post Unpaid Invoices | Post Pensoft Payroll Data | Renumber Attorney |
| Renumber Category | Renumber Vendors | Post Recurring Entries | Renumber Trust Account |
| Renumber Client | Reorganize APS Data Files | Post System/II Payroll Data | Void Checks |
| Renumber Timekeeper | Transfer Invoices | Renumber Account | |
| Renumber Transaction Code | Unpost Unpaid Invoices | Reorganize GLS Data Files | |
| Synchronize PM & TABS III/TAS | Void/Reprint Unposted Checks | System/II Payroll Interface Configuration |
| TABS III Processes | |||
| Adjust Flat Fee Clients | Delete a Range of Clients | Rebuild Receipt Allocation | Synchronize TABS III and PM |
| Adjust Split Fee Clients | Edit Client Ledger | Reindex Files | Transfer A/R and Transactions |
| Change Beginning Reporting Month | Edit Receipt Allocation | Rename Statement Template | Undo Multiple Updated Statements |
| Change Client Options | Merge Data Capture Transactions | Renumber Category | Undo Single Updated Statement |
| Change Key Type | Merge TABS III Remote Data | Renumber Client | Update Statements |
| Change WIP Transactions | Payment Adjustment | Renumber Tcode | Write-Up/Write-Down Fees & Costs |
| Clear Productivity Totals | Purge Archive Data | Renumber Timekeeper | |
| Combine Client Ledger | Rebuild Client Ledger Detail | Reverse Write Off | |
In addition to the interruption of any of the functions listed above, the following are examples of other situations in which restoring from a backup might be necessary:
Once it has been determined that you must restore from a backup, there are several things that must be taken into consideration before you proceed with the restore process.
Every STI system integrates with other STI systems. As a result, it is very important to know which systems should be restored before you begin the process of restoring data. For example, suppose the TABS III Update Statements program is interrupted. Clearly, the TABS III data files must be restored, but since TABS III and STI's Trust Accounting System share several data files, the TAS data files must also be restored at the same time. As a general rule, STI recommends that all systems be restored simultaneously. In some instances, however, you may prefer to restore the data for only certain systems and deal with integration issues during the re-entry process after restoring. The following section provides general guidelines for determining which systems must be restored together, and which can optionally be restored independently.
After erasing the data in both the Fee file and the Cost file, the
Synchronize PM and TABS III/TAS program must be run. To access the
synchronization program from the PracticeMaster menu, select
Maintenance | Integration | Synchronize PM and
TABS III/TAS. Since the PracticeMaster data will be more current than
the restored TABS III data, you will want to select the PracticeMaster data
for resolving any synchronization exceptions that occur.
Note: A result of erasing fee data is that
the link between all PracticeMaster fee records and calendar or timer records
is lost. Therefore, it will no longer be possible to run a Timer Fee Report
for WIP status fee transactions or to load a fee record associated with a
journal record or calendar entry in PracticeMaster. To avoid this situation,
restore PracticeMaster when you restore TABS III data.
Note: If any client records have been renumbered in TABS III since
the backup was made, the old Client IDs will be restored in TABS III and both
the old and new Client IDs will exist in both systems after running the
synchronization program.
If you restore only the GLS data, all GLS activity that has happened since the backup was made must be redone. However, any processes that were run in APS since the backup was made (including the above programs) will not have to be run again. As a result, any journal entries that were passed from APS to GLS since the backup was made will not be passed again to GLS as they were originally. These journal entries will have to be re-created manually.
One of the challenges associated with restoring data from a backup is knowing exactly what work must be redone after successfully restoring. Perhaps the most efficient way to make this determination is to run a series of reports (if possible) before restoring. The following tables list some of the reports that might be useful in determining what must be re-entered after restoring from a backup.
| Report Name | Description |
|
Fee Verification List Cost Verification List Payment Verification List Client Funds Verification List Split Fee Adjustment Verification List Transfer Transactions Verification List Update Statements Verification List Undo Updated Statements Verification List Write Off Verification List |
If they are available,
verification lists for each User ID make it possible to see what
transactions have been added, changed or deleted recently by each user, in
chronological order. Unlike the Transaction File List, verification lists
are not dependent upon transaction dates, which make them ideal for
reconstructing the work done during a certain period of time (e.g., in the
past three days). Note: Depending on how often each user's verification lists are deleted, each list may contain more or less information than you need to see since the backup was made. |
| Transaction File List | If verification lists are not available, a
Transaction File List (TFL) can be used to get a list of all
transactions entered for a range of days between the restore date and the
current date. Note: Because the transactions included on this report are selected by transaction date or statement date, it is important to use a date range sufficient to include any transactions that may have been entered with a prior transaction date since the backup was made. For example, if someone spent one day entering a timekeeper's time for the past two weeks and the backup was made three days ago, running the TFL for the last three days only would not include all transactions that were entered since the backup was made. If you use an earlier beginning date when running the report, many transactions that existed prior to the backup may be included on the report. |
| Client List | Printing a Client List for clients with an open date between the date of the backup and the current date makes it easy to re-enter any clients that were entered into TABS III during the interim between making the backup and restoring. Be sure to select the Detail option in the Type section of the Options tab, so that all information is printed for each client included on the report. |
| Pre-Update Statements Report | Printing a Pre-Update Statements Report creates a list of all final statements that have been run and are waiting to be updated by the Update Statements program. The report includes billed amounts for each statement, broken down by type, as well as statement dates. |
| Accounts Receivable by Invoice Report | If any user that regularly uses the Update
Statements program has no Update Statements Verification List available, the
Accounts Receivable by Invoice Report might be helpful in determining
what statements have been processed by the Update Statements program since
the backup was made. This report can be run for a range of specific
statement dates, and shows billed information for each statement that falls
within the specified date range. Note: Keep in mind that if statements with statement dates prior to the date of the backup have been updated since the backup was made, the date range entered on the Options tab of this report will need to be adjusted accordingly. |
| Pre-Bill Tracking Report | Pre-Bill Tracking is an optional feature in TABS III that makes it easy to keep track of the status of draft statements or pre-bills that have been run for various clients. If you regularly use Pre-Bill Tracking, it may be useful to print a Pre-Bill Tracking Report before restoring, for comparison to the same report printed after restoring. By doing this, you can tell what draft statements have been run, and how the status has changed for any existing pre-bill records since the backup was made. |
|
Billing Frequency List Category List Cost Type Description List Location List Statement Notes List Statement Template List Task Code List Task Code Set List Text Macro List Timekeeper Level List Timekeeper List Transaction Code List |
Depending on how long it has been since the backup was made and how often changes are made to TABS III setup and billing lookup files (e.g., categories, task codes, timekeepers, transaction codes, etc.), it might be a good idea to print lists of the records in these files before and after restoring for comparison purposes. Use these lists to help identify any changes that will need to be made after restoring. |
| Support Log | Printing a TABS III Support Log before restoring can assist with the process of data re-entry after restoring, since the log shows what User IDs have performed which critical TABS III functions and when they were done. For example, the Support Log shows the last 10 dates and times the Clear Productivity Totals program was run (under the MTD/YTD Clear Dates heading). |
| Report Name | Description |
|
Fee Verification List Cost Verification List |
If they are available, verification lists
for each TABS III Remote user make it possible to see what transactions have
been added, changed or deleted recently by each user, in chronological
order. Unlike the Transaction File List, verification lists are not
dependent upon transaction dates, which make them ideal for reconstructing
the work done during a certain period of time. Note: Depending on how often each user's verification lists are deleted, each may contain more or less information than you need to see since the backup was made. |
| Transaction File List | If verification lists are not available, a
Transaction File List (TFL) can be used to get a list of all
transactions entered for a range of days between the restore date and the
current date. Note: Because the transactions included on this report are selected by transaction date, it is important to use a date range sufficient to include any transactions that may have been entered with a prior transaction date since the backup was made. For example, if someone spent one day entering a timekeeper's time for the past two weeks and the backup was made three days ago, running the TFL for the last three days only would not include all transactions that were entered since the backup was made. If you use an earlier beginning date when running the report, many transactions that existed prior to the backup may be included on the report. |
| Report Name | Description |
| Invoice/Manual Check Verification List | If it is available, an Invoice/Manual
Checks Verification List makes it possible to see what invoices and
manual checks have been added, changed or deleted recently by each user, in
chronological order. Unlike other reports available in APS, the verification
list is not dependent upon invoice date, due date or check date, which makes
it ideal for reconstructing the work done during a specific period of time. Note: Depending on how often each user's verification lists are deleted, each may contain more or less information than you need to see since the backup was made. |
| Paid Invoices by Vendor Report | A Paid Invoices by Vendor Report provides a list of checks for a specified date range, sorted by vendor. This report can be run separately for posted checks and unposted checks. It should be printed using the same criteria both before and after restoring (i.e., four times total, including once for posted checks and once for unposted checks both before and after restoring). The two versions of the report can then be compared to determine which checks have been printed, and which printed checks have been posted, in the interim. Any checks printed since the backup was made can then be re-entered as manual checks with the correct check numbers, and do not need to be physically printed again. Any checks posted since the backup was made will need to be posted again. |
| Invoice by Vendor List | If an Invoice/Manual Checks Verification
List is not available, printing the Invoice by Vendor List for unpaid
invoices both before and after restoring offers an alternative means of
determining which invoices have been entered or changed in APS since the
backup was made. Note: Because the invoices included on this report are selected by invoice date, due date or check date, it is important to use a date range sufficient to include any invoices that may have been entered with a prior invoice date since the backup was made. For example, if a week's worth of invoices have been entered since the backup was made three days ago, running the Invoice by Vendor List for the last three days only would not include all invoices that were entered since the backup was made. An Invoice by Vendor List can also be run for all posted unpaid invoices and/or all unposted unpaid invoices, both before and after restoring from a backup. If you use the Post Unpaid Invoices program in APS, printing this report with specific options selected on the Options tab can help you determine which unpaid invoices may need to be posted or unposted again after restoring. Note: The Post Unpaid Invoices and Unpost Unpaid Invoices programs are most commonly used by firms that use an accrual method of accounting. You may not need to run the Invoice by Vendor List for posted and unposted unpaid invoices if your firm uses a cash method of accounting. |
| Voided Check List | Printing a Voided Check List before restoring from a backup lets you see what checks have been voided since the backup was made. This information may or may not be useful; if the only checks that were voided were for invoices entered since the backup was made, you may prefer simply to not enter (or else not pay) the invoices after restoring instead of going to the extra step of voiding them. On the other hand, checks that were in the system when the backup was made and have since been voided will need to be voided again after restoring. |
| Recurring Entry List | The optional Recurring Entry List can be printed both before and after restoring to ensure that any additions or changes to APS recurring entries made since the backup was created can be accounted for and recreated after restoring from the backup. |
| Vendor List | It may be a good idea to print a Vendor List before and after restoring from a backup to ensure that any vendors added, changed or deleted since the backup was made can be accounted for after restoring from the backup. |
| Bank Account List | It may be a good idea to print a Bank Account List before and after restoring from a backup to ensure that any bank accounts added, changed or deleted since the backup was made can be accounted for after restoring from a backup. |
| Support Log | Printing an APS Support Log before restoring can assist with the process of data re-entry after restoring, since the log shows what User IDs have performed which critical APS functions and when they were done. For example, the Support Log shows the last 10 dates and times the Reorganize APS Data Files program was run (under the File Reorganization heading). |
| Report Name | Description |
| Journal Entry Verification List | If it is available, a Journal Entry
Verification List makes it possible to see what GLS journal entries have
been added, changed or deleted recently by each user, in chronological
order. Unlike other reports available in GLS, a Journal Entry
Verification List is not dependent upon journal entry date, which makes
it ideal for reconstructing the work done during a certain period of time. Note: Depending on how often each user's verification lists are deleted, each may contain more or less information than you need to see since the backup was made. |
| Journal Report | If a Journal Entry Verification List is not
available, a Journal Report can be used to get a list of journal
entries that have dates between the date of the backup and the date of
restoring. Note: Because the journal entries included on this report are selected by record date, it is important to use a date range sufficient to include any journal entries that may have been created with a prior date since the backup was made. For example, if someone spent one day entering a journal entries for the past two weeks and the backup was made three days ago, running the Journal Report for the last three days only would not include all entries that have been created or changed since the backup was made. If you use an earlier beginning date when running the report, many journal entries that existed prior to the backup may be included on the report. |
|
Balance Sheet Trial Balance Income Statement |
GLS financial statements can be printed before and after restoring for comparison after re-creating or changing the journal entries that have been created or changed since the backup was made. Be sure to use the same report criteria when running each set of reports. |
| Check Reconciliation Report | Every time you exit the Check Reconciliation program, GLS provides you with the opportunity to save your progress. If the reconciliation process is under way when it becomes necessary to restore from a backup, a Check Reconciliation Report can be printed before restoring so that after you restore, the process of retracing the reconciliation steps that have already been taken can be expedited. |
| Recurring Entry List | It may be useful to print the Recurring Entry List before restoring from a backup. This report shows all recurring entries configured in the General Ledger System, and comparing pre-restore and post-restore versions of this report will help you determine whether any recurring entries have been added, changed or deleted since the backup was made. |
| Chart of Accounts List | Printing a Chart of Accounts List both before and after restoring from a backup will help you keep track of any GLS accounts that have been added, changed or deleted since the backup was made. To facilitate easy comparison, it is very important to use the same options each time you print this report. |
| Budget Report | A Budget Report lists the budget figures you can optionally enter for each GLS account. If any budget figures have been changed since the backup was made, it is a good idea to print this report before and after restoring from a backup, to ensure that those changes are recreated correctly after restoring. |
| Support Log | Printing a GLS Support Log before restoring can assist with the process of data re-entry after restoring, since the log shows what User IDs have performed which critical GLS functions and when they were done. For example, the Support Log shows the last 10 dates and times the Month-End/Year-End Close-Out program was run (under the MTD/YTD Close Dates heading). |
| Report Name | Description |
| Transaction Entry Verification List | If it is available, a Transaction Entry
Verification List makes it possible to see what check, EFT and deposit
transactions have been added, changed or deleted recently by each user, in
chronological order. Unlike other reports available in TAS, the verification
list is not dependent upon transaction date, which makes it ideal for
reconstructing the work done during a certain period of time. Note: Depending on how often each user's verification lists are deleted, each may contain more or less information than you need to see since the backup was made. |
| Check Register by Trust Account | If a Transaction Entry Verification List is
not available, a Check Register by Trust Account can be used to get a
list of transactions that have dates between the date of the backup and the
date of restoring. Note: Because the transactions included on this report are selected by transaction date, it is important to use a date range sufficient to include any transactions that may have been entered with a prior transaction date since the backup was made. For example, if someone spent one day entering trust transactions for the past week and the backup was made three days ago, running the Check Register by Trust Account for the last three days only would not include all transactions that have been entered since the backup was made. If you use an earlier beginning date when running the report, many transactions that existed prior to the backup may be included on the report. |
| Voided Check List | Printing a Voided Check List before restoring from a backup lets you see what checks have been voided since the backup was made. This information may or may not be useful; if the only checks that were voided were for transactions entered since the backup was made, you may simply prefer to not enter (or else not print checks for) those transactions after restoring instead of going to the extra step of voiding them. On the other hand, checks that were already in the system when the backup was made and that have since been voided will need to be voided again after restoring. |
| Bank Account Reconciliation Report | Every time you exit the Bank Account Reconciliation program, TAS provides you with the opportunity to save your progress. If the reconciliation process is under way when it becomes necessary to restore from a backup, a Bank Account Reconciliation Report can be printed before restoring so that after you restore, the process of retracing the reconciliation steps that have already been taken can be expedited. |
| Trust Account List | Printing a Trust Account List for trust accounts with an open date between the date of the backup and the current date makes it easy to re-enter any accounts that were entered into TAS during the interim between making the backup and restoring. Be sure to select the Detail option in the Report Type section of the Options tab, so that all information is printed for each trust account included on the report. |
| Payee List | If you print a Payee List for all payees both before and after restoring from a backup, you can compare the two after restoring to determine whether any payee records have been added, changed or deleted since the backup was made. |
| Bank Account List | If any bank accounts have been added or changed since the backup was made, it is a good idea to print a Bank Account List before restoring from a backup. This will ensure that the changes can be easily and accurately recreated after restoring. |
| Attorney List | If you are not integrating with STI's TABS
III system, it might be a good idea to print an Attorney List before and
after restoring for comparison, to ensure that any additions, changes or
deletions of attorney information that may have occurred since the backup
was made can be easily and accurately recreated after restoring. Note: If you are integrating with TABS III, there is no need to print an Attorney List before restoring since changes to the attorney information can only be made in TABS III and all TABS III data must be restored when you restore TAS. Printing the TABS III Timekeeper List as described in the previous TABS III Reports section will provide you with the information required to ensure that any changes to timekeeper/attorney information since the backup was made can be easily and accurately recreated after restoring. |
| Support Log | Printing a TAS Support Log before restoring can assist with the process of data re-entry after restoring, since the log shows what User IDs have performed which critical TAS functions and when they were done. For example, the Support Log shows the last 10 dates and times the Reindex Files program was run (found under the File Reorganization heading). |
| Note: The
flexibility and level of customization provided by PracticeMaster allows
virtually any type of data to be entered, recorded, tracked and reported on,
in any number of ways and formats. Due to the open-ended nature of the
PracticeMaster system, there is no way to provide instructions regarding
reports that should be run prior to restoring from a backup. The powerful
Report Writer feature built into PracticeMaster (Reports |
Report Writer) lets you design custom reports specific to your
practice, and can be used to help gather some of the data that may need to
be re-entered after restoring. When designing reports for this purpose, it is important to keep in mind that any record in any PracticeMaster file can be entered with any date (regardless of whether the file was included with the system by default or custom designed by you). As with other systems' transaction reports, because records may have been entered with prior dates, running a report for records dated since the backup was made may not be sufficient to show all activity that has occurred in that time frame if records with prior dates have been entered or changed since the backup was created. In addition, unless you have configured date fields to be required in your files, it is possible that some records may have been entered with no date at all. Finally, keep in mind that some PracticeMaster files may not even include fields related to date information at all. Keep these things in mind as you review the list below, which gives examples of some reports that are provided by default with PracticeMaster and may be helpful in gathering information on some of the activity that has occurred since the backup was made. |
|
| Report Name | Description |
| Calendar Reports | Running reports such as the Calendar by Due Date and Calendar by User (_CALDUE.RW and _CALUSER.RW, respectively) may provide some assistance in determining what calendar entries have been made since the backup was created. Keep in mind that since it is common to make calendar entries for future dates, using a more limited date range when running the report translates to a greater likelihood that the report may not include some activity that has occurred since the backup was made. |
| Client and Related Party Reports | Consider printing client and related party
reports such as the Master Client/Case List (_CLNTLST.RW) and the
Detail Related Party List (Rp_det.RW) before and after restoring. These
reports can be compared to determine what activity has occurred since the
backup was made. If you already know specifically which clients have been added to PracticeMaster since the backup was made, it may be useful to print a Client Summary Report (Systmsum.RW) before restoring, as well. |
| Client Related Reports | It may be useful to print client related reports such as the Client/Case Expense Summary (_CLNTEXP.RW or _CASEEXP.RW), Client/Case Time Summary (_CLNTTIM.RW or _CASETIM.RW), and various journal reports such as the Journal by Date Report (JRNLDATE.RW) before restoring from a backup. If PracticeMaster is configured to integrate with TABS III, transaction-specific reports may not be necessary since they can be run in TABS III (if restoring both systems) or the data can be integrated to PracticeMaster from TABS III after restoring (if restoring only PracticeMaster). |
| Custom Reports | It may be a good idea to run any custom reports that show the contents of customizable files such as Area of Practice files, Common Client Related files and User Defined Lookup files. For example, before restoring, a law firm might want to run a report detailing the records in the Claimant Information file for the Workers Compensation Area of Practice. The same report could then be run after restoring, for comparison to the pre-restore copy of the report. |
| Setup Related Reports | Printing reports such as the Calendar Code List (Cal_code.RW), Transaction Code List (Tcode.RW), Category List (Category.RW) and Text Macro List (Macro.RW) before and after restoring make it possible to compare and determine what activity has occurred since the backup was made. |
If possible, you may want to make some control entries before restoring from a backup, to help ensure that the restore process is successful. The use of control entries is an effective technique that can be helpful if there is a question as to whether the data was restored successfully to the correct location. Once the restore operation has completed, you can check the data to verify that the control entries are not present. If they are still in your data, the restore was NOT successful, since restoring files from a backup should overwrite all existing data.
The following are some examples of possible control entries. As an example of the distinctive descriptions suggested below, you might use a phrase such as, "TEST ENTRY - FOR RESTORING CONTROL PURPOSES ONLY!".
| System to Be Restored | Suggested Control Entries |
| TABS III | Create a test client with a Client ID well beyond the next available number. Enter a sample fee transaction, a sample payment transaction and a sample cost transaction for the test client with distinctive descriptions. |
| APS | Create a test vendor with a vendor number well beyond the next available number. Enter a sample invoice for the test vendor with a distinctive description. |
| GLS | Create a test account with an account number that is distinct from any existing accounts. Enter a sample journal entry (or batch of journal entries) to the test account, using distinctive descriptions. |
| TAS | Create a test trust account with a Trust ID well beyond the next available number. Enter a sample Deposit and a sample EFT for the test account, using distinctive descriptions. |
| PracticeMaster | Create a test related party record with a distinctive Related Party Key. Enter a sample calendar record and a sample journal record for the test related party, using distinctive descriptions. |
This section lists the naming conventions of the data files located in the program directory that should be restored from your backup over the existing data.
| System to be Restored | Files to Restore |
| TABS III | T3*.*, *.T3R, *.T3D, *.TLX, *.TOC, T4*.*, *.TRD Note: It is imperative that you check the TABS III archive path before restoring, and restore T3*.* from that directory as well. To check the archive path:
|
| APS | A3*.*, *.APD, *.TOC |
| GLS | G5*.*, *.GLD, *.TOC Note: Each GLS client may have its own separate data directory. When restoring GLS data for a given client, it is important to determine the client's data directory first, to ensure that files from the correct location are restored. In other words, the GLS data is not necessarily always located in the same directory as the GLS program files. To check the current GLS client's data path:
|
| TAS | T4*.*, *.TRD, T3*.*, *.T3R, *.T3D, *.TOC |
| PracticeMaster | CM*.DAT, CM*.IDX, the entire contents of the
CMSYSTEM subdirectory, and the entire contents of any other PracticeMaster
related directories. Note: Because PracticeMaster configuration and data files can be heavily customized, and new files and folders can be created, it is not possible to list a static set of filenames or directories that must be restored when restoring PracticeMaster. |
| STI System Configuration | ST*.DAT, ST*.IDX |
Any time data is restored from a backup, the next step is to always run the Data File Integrity Check program in all affected STI systems, and to run the Archive Data Integrity Check program in TABS III. There are two reasons why this is necessary:
The Data File Integrity Check program is available from the menu in all STI Systems by selecting the Utilities | Data File Integrity Check. The TABS III Archive Data Integrity Check program can be accessed from the TABS III menu by selecting Utilities | Archive Integrity Check.
Once all integrity check programs have completed with no errors, go into each STI system for which the data has been restored and check the data to ensure that it is consistent with the data that you were expecting to see after restoring. For example, if your backup was made three days ago, you should not see any entries or changes that have been made since then. If you made the optional control entries before restoring, verify that they are NOT present in the data now. This is another means of ensuring that the data was restored successfully. If you see entries or changes that were made more recently than the backup from which you restored (e.g., the optional control entries), the restore process was not successful and you should attempt to troubleshoot the cause of the failure and then try restoring again.
When you have determined that the restore operations have completed successfully, the final step is to redo all additions, changes or deletions to STI data that have occurred since the backup was made. Depending on the amount of time that has passed since the backup was made, this can be a very brief process or a very lengthy one. Often, firms that have to restore, will designate an individual or a select group of individuals to be responsible for nothing but data re-entry until this process is completed.
The reports printed prior to restoring can be used to help determine what must be re-entered. In many cases, you will run the same reports again after restoring the data but before beginning re-entry, to compare the two versions of a given report and find out what differences, if any, exist between them. In some cases, you will rerun certain reports after all data has been re-entered, to ensure that it has been done correctly (as described in the Reports to Run Before Restoring section above).
If data has been restored for only some STI systems (but not all systems), it is very important when re-entering data that has been overwritten by the restore process to keep in mind the integration considerations involved in restoring data.
THE INFORMATION PROVIDED IN THE SOFTWARE TECHNOLOGY, INC. KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. SOFTWARE TECHNOLOGY, INC. DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SOFTWARE TECHNOLOGY, INC. OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF SOFTWARE TECHNOLOGY, INC. OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
© 1999-2003 Software Technology, Inc. All rights
reserved.
Knowledge Base: http://support.Tabs3.com
Web Site: http://www.Tabs3.com