|
|
|
|
The information in this article applies to:
Utilizing the built-in back up and restore programs included with every Tabs3 and PracticeMaster product is the most convenient way of backing up and restoring data in the software. However, in the event that you are unable to use these built-in programs, this article discusses guidelines and procedures for restoring Tabs3 and PracticeMaster data from an external 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.
Note: This article discusses the built-in Back Up Data Files program. For information about restoring a HotBackup file, included in Version 15 and 14.3 Client Server Version (CSV) Software, see KB Article R11199, "Restoring a HotBackup".
What Does it Mean to Back Up Your Data?
Running the Data File Integrity Check Before Backing Up
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 Tabs3 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 Software Reports
General Ledger Software Reports
Trust Accounting Software Reports
After Restoring Data from a Backup
Backing up your Tabs3 and PracticeMaster 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 Tabs3 and PracticeMaster 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. KB 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. Software Technology, Inc. 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, we recommend that you take advantage of the built-in backup utility provided with all Tabs3 and PracticeMaster Version 15, 14, 12, and 11 systems. Additional information regarding the use and function of the internal backup utility is available in KB Article R10278, "Troubleshooting the Built-In Backup Program."
Restoring data from a backup means copying all Tabs3 and PracticeMaster 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 Tabs3 and PracticeMaster 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 Tabs3 data due to corruption in the Client file, you must restore ALL Tabs3 data files and not just the Client file. This is because the data files contain information closely related to all other files for the same system. Likewise, integration between the Tabs3 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 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 |
Accounts Payable Software |
General Ledger Software |
Trust Accounting Software |
|
Change Key Type |
Change Key Length |
Advance Current Reporting Month |
Change Key Type |
|
File Maintenance |
Import Invoices |
Change Account Number Format |
Import Transactions |
|
QuickBooks Integration |
Post ChecksC |
Change Fiscal Year |
Purge Trust Transactions |
|
Reindex Files |
Post Recurring Entries |
Post ASCII Data |
Reindex Files |
|
Renumber Category |
Post Unpaid Invoices |
Post PenSoft Payroll Data |
Rename Payee |
|
Renumber ClientC |
Renumber Vendors |
Post Recurring Entries |
Renumber Attorney |
|
Renumber Timekeeper |
Reindex Files |
Post Tabs3/TAS Accrual Balances |
Renumber Trust Account |
|
Renumber Transaction Code |
Select Invoices to PurgeC |
Renumber Account |
Void ChecksC |
|
Synchronize PM & Tabs3/TAS |
Transfer InvoicesC |
Reindex Files |
|
|
|
Unpost Unpaid Invoices |
|
|
|
|
Unpost Single Unpaid Invoice |
||
|
Void Posted ChecksC |
|||
|
Void/Reprint Unposted ChecksC |
|
1 Programs in the above list are for Version 15. The following programs from earlier versions also required restoring from a backup in the event it was interrupted: PM: Check In Briefcase, Process Timer Records; APS: Clear Vendor Analysis Totals; GLS: Month/Year-End Close-Out, Post Great Plains Payroll Data, Post System/II Payroll Data, and System/II Payroll Interface Configuration.
C When running the Client Server Version (CSV) software, it is not necessary to restore in these situations because the process is protected by Transaction Processing (R11175). Instead, rerun the process.
|
Tabs3 Processes2 |
||
|
Adjust Flat Fee ClientsC |
Reindex Files |
Transfer A/R and TransactionsC |
|
Adjust Split Fee ClientsC |
Rename Statement TemplateC |
Undo Multiple Updated StatementsC |
|
Change Beginning Reporting Month |
Renumber Category |
Undo Single Updated StatementC |
|
Change Client OptionsC |
Renumber ClientC |
Update StatementsC |
|
Change Key Type |
Renumber Tcode |
Write Off ClientC |
|
Change WIP TransactionsC |
Renumber Timekeeper |
Write-Up/Write-Down Fees & CostsC |
|
Advance Current Reporting Month |
Reverse Write OffC |
|
|
Payment AdjustmentC |
Synchronize Tabs3 and PM |
|
2 Programs in the above list are for Version 15. The following programs from earlier versions also required restoring from a backup in the event it was interrupted: Clear Productivity Totals, Combine Client Ledger, Delete a Range of Clients, Edit Client Ledger, Edit Receipt Allocation, Merge Data Capture Transactions, Merge PracticeMaster Client Changes, Merge Tabs3 Remote Data, Purge Archive Data, Rebuild Client Ledger Detail, QuickBooks Integration, and Rebuild Receipt Allocation.
C When running the Client Server Version (CSV) software, it is not necessary to restore in these situations because the process is protected by Transaction Processing (R11175). Instead, rerun the process.
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.
Tabs3, PracticeMaster, and Tabs3 Financial Software products integrate with each other in various capacities. 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 Tabs3 Update Statements program is interrupted. Clearly, the Tabs3 data files must be restored, but since Tabs3 and Tabs3 Trust Accounting Software (TAS) share several data files, the TAS data files must also be restored at the same time. As a general rule, we recommend 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.
Note: The Version 15 and 14.3 built-in back up and restore programs automatically back up and restore all systems, regardless of which product the program is run from. For example, if your firm uses Tabs3, PracticeMaster, and General Ledger Software (GLS), executing the Back Up Data Files program in PracticeMaster will create a single backup file that contains the data for all three products. Likewise, if you were to run the Restore Data Files program in Tabs3 after creating a backup, it would restore the data files for Tabs3, PracticeMaster, and GLS. Additional information is available in KB Article R11167, "Built-In Back Up and Restore Programs."
After erasing the data in both the Fee file and the Cost file, the
Synchronize PM and Tabs3/TAS program must be run. To access the
synchronization program from the PracticeMaster menu, select
Maintenance | Integration | Synchronize PM and Tabs3/TAS. Since the PracticeMaster data will be more current than
the restored Tabs3 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 Tabs3 data.
Note: If any client records have been renumbered in Tabs3 since
the backup was made, the old Client IDs will be restored in Tabs3 and both
the old and new Client IDs will exist in both systems after running the
synchronization program.
If any GLS account numbers have been renumbered since the backup was made
in Tabs3, remember to modify the GL Debit Acct and GL Credit Acct
fields for each Tabs3 tcode that is configured to integrate with GLS after
successfully restoring the Tabs3 data. (To access tcode setup from the Tabs3 menu, select
File | Open | Miscellaneous
and then click the TransCode tab.)
Version 14.1, 12 & 11 Only:
After erasing the data in both the Fee file and the Cost file, the
Synchronize PM and Tabs3/TAS program must be run in PracticeMaster. To
access the synchronization program from the PracticeMaster menu, select
Maintenance | Integration | Synchronize PM and
Tabs3/TAS. Since the Tabs3 data will be more current than the
restored PracticeMaster data, you will probably want to select the Tabs3 data in resolving any synchronization exceptions to 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 Tabs3 data.
Note: If any client records have been renumbered in PracticeMaster
since the backup was made, the old Client IDs will be restored in
PracticeMaster 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 |
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). |
|
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. Be sure to select transactions based on Entry Date (as opposed to Transaction Date). |
|
|
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 Tabs3 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. |
|
|
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. |
|
|
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. |
|
|
Pre-Bill Tracking is an optional feature in Tabs3 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 |
Depending on how long it has been since the backup was made and how often changes are made to Tabs3 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. |
|
Printing a Tabs3 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 Tabs3 functions and when they were done. For example, the Support Log shows a list of dates and times the Clear Productivity Totals program was run (under the MTD/YTD Clear Dates heading). |
|
Report Name |
Description |
|
If they are available, verification lists
for each Tabs3 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. |
|
|
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. |
|
Report Name |
Description |
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 a list of dates and times that changes were made to the Vendor file. |
|
Report Name |
Description |
|
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. |
|
|
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. |
|
|
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. |
|
|
Every time you exit the 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 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. |
|
|
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 Software, 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. |
|
|
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. |
|
|
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. |
|
|
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 a list of dates and times the Month-End/Year-End Close-Out program was run (under the MTD/YTD Close Dates heading). |
|
Report Name |
Description |
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
If you are not integrating with Tabs3, 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. |
|
|
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 a list of dates and times the Reindex Files program was run (found under the Reindex Files 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. |
|
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 Tabs3, transaction-specific reports may not be necessary since they can be run in Tabs3 (if restoring both systems) or the data can be integrated to PracticeMaster from Tabs3 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 |
|
Tabs3 |
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 |
|
Tabs3 |
T3*.*, *.T3R, *.T3D, *.TLX, *.TOC, T4*.*, *.TRD
|
|
APS |
A3*.*, *.APD, *.TOC |
|
GLS |
G5*.*, *.GLD, *.TOC
|
|
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. |
|
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 systems, and to run the Archive Data Integrity Check program in Tabs3. There are two reasons why this is necessary:
The Data File Integrity Check program is available from the menu in all Tabs3 and PracticeMaster software by selecting the Utilities | Data File Integrity Check. The Tabs3 Archive Data Integrity Check program can be accessed from the Tabs3 menu by selecting Utilities | Archive Integrity Check.
Once all integrity check programs have completed with no errors, go into each 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 the Tabs3 and PracticeMaster 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 Tabs3 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-2010 Software Technology, Inc. All rights
reserved. Terms of Use
The maker of Tabs3 and PracticeMaster
Tabs3, PracticeMaster, and the “pinwheel” symbol (
) are registered trademarks of Software Technology, Inc.
e-Mail Suggestions for the Knowledge Base to: kb@Tabs3.com
Technical Support via e-mail is not available.
Knowledge Base: http://support.Tabs3.com
Web Site: http://www.Tabs3.com
