| Home | RDP Sales | Contact Us | Training |
|
| RDP Support | ||||
|
RDPWin Knowledge Base |
RDP-DOS Knowledge Base |
IRM and IRM.Net Knowledge Base |
Crystal Knowledge Base |
|
Article ID: K000191
Added: 3/24/2006
Updated: December 2007
Resort Data Processing (RDP) has been in business over 25 years, and we have sold well over 1,000 systems. We have many customers who have successfully used the system for 10, 20, or more years! The system is designed to hold all historical data forever. However, after a long period of time the database can become very large, which can lead to performance problems. Additionally system backups are very large and system utilities can also run for a a long time to read all the historical data.
RDP suggests that all customers update their RDP programs to the latest versions and purge the oldest historical data with the procedures in this article every six months.
Each of the steps on this checklist is explained below. Please print this page and check each step when complete.
| # | Description | Complete |
|---|---|---|
| 1 | Make a full system backup and keep it | __________________ |
| 2 | Download a current DOS, IRM and RDPWin update | __________________ |
| 3 | Delete old Log files | __________________ |
| 4 | Transfer Active History Reservations to Non-Active History - RDP910-01 | __________________ |
| 5 | Delete reservations from non-active history - RDP990-4 | __________________ |
| 6 | Rebuild Non-Active Reservation History Key File - Option 910-2 | __________________ |
| 7 | Clean-up the auxiliary historical files - Option 910-3 | __________________ |
| 8 | Set Switch 426-9 "Number of years to keep Statistics Detail" | __________________ |
| 9 | Rebuild Critical Data Files - RDP994 - Rebuild All Critical Files | __________________ |
| 10 | Delete Files created by RDP994 - Rebuild All Critical Files | __________________ |
The first step is to make a full backup of the RDP system and keep the backup to restore old data if it is ever needed.
Update all RDP programs to the current version. All directions in this article assume you have the current release of RDPDOS, RDPWin, and the IRM (Internet Reservation Module). Updates to all three products are available on: Customer Support Home Page
The RDP system creates many daily log files which are designed to troubleshoot problems with RDP interfaces, the Internet Reservation module, and other systems. These log files should be kept on the system for the current year, but can safely be deleted for prior years with the procedure below. These log files can be quite large and a great deal of disk space can become free with the procedure below:
Make sure you have made a full system backup and also have the current RDPDOS update
All users can remain in the system
Start Windows Explorer, and navigate to the \RDP\RDP01 folder. You should see a file "RDPDEL.BAT".
Double-click the "RDPDEL.BAT" file to run the file.
If you have more than one RDP data directory, copy the RDPDEL.BAT file to each RDP data directory and run it.
Warning: The RDPDEL.BAT file is designed to be executed only from a data directory, such as \RDP\RDP01 or \RDP\RDP02. If you have multiple RDP data directories you must copy the RDPDEL.BAT file to each data directory and run it from that directory.
The RDP system maintains an active reservation file and a non-active reservation history file. Periodically you must use menu 99, option 910-01 to transfer reservations from the active reservation file to the non-active reservation file. The table below summarizes these two files:
| File Name | Purpose |
|---|---|
| HRESERVE.DAT
Future |
The HRSERVE.DAT file holds all future, in-house and active
history reservations.
|
| BOOKHIST.DAT
Active History Only |
The BOOHIST.DAT file holds all active history
reservations.
|
RDP recommends transferring reservations from the active reservation file to the non-active reservation file every day during the night audit process. If you do not have a night audit, the process can be done once a week, or once a month, as follows:
All workstations can remain in the system during this process
Use menu 99, option 090 - Update System Tables
Select Table C1, sub-record "910". The "special data" field determines how many days a reservation is kept in the active history file. The default is 60 days. RDP suggests setting this between 60-180 days..
Enter the number of days in the special data field and enter "F" to file the information
There are four switches that apply to RDP910-Transfer. Review these settings. Please call RDP support at 970-845-7108 if you have any questions:
| Switch | Wording |
|---|---|
| 109-11 | Keep canceled reservations until their departure
date.
|
| 219-14 | Transfer ALL canceled reservations to non-active
history
|
| 425-16 | Turn off Security Deposit & Transfer Open
Security Deposits to Non-Active:
Note: A security deposit is held against damage to the room and refunded to the guest after checkout if there is no damage. This is not the same as an "advance deposit". |
| 426-8 | Transfer reservations to non-active if balance is
< 1.00
|
From menu 99, run option 910, sub-option "1" - "Transfer Reservation from Active to Non-Active History".
Press <Enter> to take the default number of transfer days, which starts the RDP910 transfer process.
When the transfer process is complete, press <F9> to view the logfile. Look for any reservations that did not transfer that should have. Call RDP support if needed. NOTE: You can also look at this file using NOTEPAD. The file is in the RDP data directory (\RDP\RDP01), and is named "RDP910.Log". Each time RDP910-01 is run this file is erased and recreated.
The system maintains a guest history file AND a non-active reservation history file. If a guest stays at the property 10 times, they will be in guest history one time, but in reservation history 10 times. The reservation history includes all notes, transactions, activities, and comments related to those reservations
Non-Active Reservation History is stored forever. As a result, the non-active history files can become very large over time and cause performance issues. RDP suggests deleting the oldest reservations from non-active history periodically, perhaps once every six months. The guest will still be in the GUEST history file even if the reservation is deleted from Reservation history. The procedure to completely delete reservations from non-active history is:
All workstations can remain in the system during this process
Make a full system backup. Once the reservations are deleted from non-active history, they are completely removed from the RDP system.
Use menu 99, option 990 - General File Utility".
Select sub-option 4, "Non-Active History: Delete reservations based on departure date". You will be prompted for, "Purge Non-active history reservations prior to what departure date? MM/DD/YY
Be careful when entering the departure date - once deleted, reservations are completely gone from the system. If you enter 12/31/2004, all reservations with a departure date on or before 12/31/2004 are deleted, along with all their notes, transactions, comments, and itinerary information. The guest will remain in the GUEST history file.
Note: After deleting information with RDP990-4, the data base will still be the same size on the disk. When a record is deleted from a database it creates an "empty hole", which can be filled by the new record. To eliminate all the "empty holes" created by deleting historical information, it is critical to follows the steps below for "Rebuild Critical Data Files"
After deleting historical reservation in the prior step the non-active history key file needs to be optimized, as follows:
All workstations can remain in the system during this process
Use menu 99, option 910 - "Transfer to Historical Files".
Select RDP910 option 2, which is "Rebuild Non-Active Reservation History Key File (BOOKKEYS.DAT)
Enter "Y" to proceed.
Over the years using the system, it is possible that information regarding a historical reservation may be in more than one file. For example, a reservation may have ten transactions on the folio, a note, and four activities on the itinerary. RDP has provided a utility to make sure all the data from deleted historical reservations is gone from all the files. All customers should use the procedure below immediately after the prior step, running RDP990 option 4 to delete reservations from non-active history as follows:
All workstations can remain in the system during this process
Make a full system backup. Once the reservations are deleted from non-active history, they are completely removed from the RDP system.
Complete the steps in the prior section - Completely delete reservations from non-active history - RDP990-4
Use menu 99, option 910 - "Transfer to Historical Files".
Select RDP910 option 3, which is "Clean-up the auxiliary historical files.
Enter "Y" to proceed.
The system tracks historical occupancy statistics as well as a forecast of future occupancy. The historical detail is stored in the file STATFILE.DAT. One record is added to this file for each occupied room each day. Over the years this file can become very large, which can cause performance problems. By default, the system keeps the occupancy statistic detail for the current year and one full year in the past. To change this default:
Start RDPDOS
Menu 98, option 426. Change switch 9, "Number of years to keep statistical detail". The default and minimum is "1", which means "keep the current year and one year in the past". The maximum is 99 years. However, most customers should leave this at 1, or perhaps 2 years in the past.
Setting switch 426-9 does not actually delete any data from STATFILE.DAT. To purge the old data, option 994 - Rebuild a data file must be used on file 63-Statfile.dat which is done in the next step.
When a record is deleted from a database it creates an "empty hole", which can be filled by the new record. If there are a large number of "holes" system performance will degrade. To improve performance as well as check for data integrity, RDP suggests rebuilding all critical files under the following conditions:
After deleting a large number of reservations from non-active history with RDP990-4. See step 5, "Completely delete reservations from non-active history - RDP990-4"
After upgrading from one version of the Pervasive database to another to convert the database to the new Pervasive Format. Each new version of Pervasive will increase performance dramatically if the database is in the "new version file format".
Periodically to verify system data integrity, perhaps once a month.
The process of Rebuilding all Critical data files to improve performance and data integrity is:
Exit all users from the system. It is not possible to Rebuild data files while the system is in use
Verify the setting for switch 426-9, the Number of years to keep Statistics Detail. When you rebuild all critical data files, the old records in the STATFILE.DAT will not be copied to the new file based on the setting of switch 426-9.
Use the fastest workstation at the property for this process to reduce the time
From Menu 99, choose option 994, sub option "C" - Rebuild all Critical files
RDP994 will copy every valid record in all critical data files. RDP994 will never corrupt data, but it will identify data that was already corrupted. For example, assume you have 10,000 future reservations. If all 10,000 reservations are successfully copied to the new file, RDP994 moves on to the next data file. However, lets assume that one of the 10,000 reservations was stored on a damaged section of the disk. RDP994 will only be able to copy 9,999 records, and report one record as "not copied". When RDP994 cannot copy all records, you are provided the option to "keep the old file or the new file". You have three choices, as follows:
| Choice | Explanation |
|---|---|
| Keep Old,
Damaged File
Not Suggested |
You can keep the old, damaged file, but this is not recommended. If you keep the old file, every time you attempt to access any of the damaged records with RDPDOS, RDPWin, or Crystal reports, you will receive a "STAT 2", and the system will terminate. RDP suggests one of the two options below. |
| Replace old damaged file with New File with missing records | The second option is to replace the old,
damaged file with the new file that was created by RDP994. The new
file is a non-corrupted file, but it will be missing all records that
could not be copied from the old file. It is not possible to
identify which records were not copied to the new file since these
records were on a damaged section of the disk drive and are not readable
at the hardware level.
If only a few records have been lost, RDP suggests replacing the old damaged file with the new file. If a large number of records have been lost, RDP suggests restoring a system backup from prior to the damage and re-entering all data. See below. |
| Restore a Backup and Re-enter data | If a large number of records have been lost,
please call RDP support at 970-845-7108 to decide on a course of
action. Depending on what data file or files are corrupted, you
may be able to restore only the corrupted file. Or, you may have to
restore the complete RDP system. In either case, you will have to
re-enter all data that was entered since the backup.
Note: Data is usually corrupted by a hardware failure or environmental problems, such as power failures, lighting strikes, etc. Some data corruption is so extensive that the only solution is to restore a full backup - which is why it is critical to make a full RDP system backup every day! |
After running RDP994 - Rebuild all Critical files, the system has two copies of each critical file. The active file has an extension of ".DAT", such as "HRESERVE.DAT". The older file has an extension of ".OLD". These ".OLD" files can now be deleted as follows:
Start Windows Explorer, and navigate to the \RDP\RDP01 folder. You should see a file "RDPDEL.BAT".
Double-click the "RDPDEL.BAT" file to run the file.
If you have more than one RDP data directory, copy the RDPDEL.BAT file to each RDP data directory and run it.
Warning: The RDPDEL.BAT file is designed to be executed only from a data directory, such as \RDP\RDP01 or \RDP\RDP02. If you have multiple RDP data directories you must copy the RDPDEL.BAT file to each data directory and run it from that directory.
| Supported Environments as of10/15/08 See Hardware Requirements for an entire list. |
|
|---|---|
| Workstations | All workstations must use either Windows XP Professional or Windows Vista (Business or Ultimate) 32-bit only (not 64 bit on workstations) with all service packs installed . RDP no longer supports Windows 95, 98, ME, or 2000 Workstations. For RDPWin, a minimum of 1 GB of RAM and a dual core processor or faster are required. See Hardware Requirements for an entire list. |
| Servers | The data server must be Windows 2003 or 2008 32 or 64 bit with all service packs installed and at least 4GB of RAM (16 for customers with 20 or more workstations). RDP no longer supports Novell Netware Servers. Feel free to call RDP Support at 970- 845-7108 with any hardware questions. |
| Pervasive | The Pervasive database must be Version 9.52 or higher with all Service Packs installed. See Pervasive Overview. |
| Printing Issues | RDPWin supports all standard Windows Printing environments. Our legacy RDP-DOS system may not be able to print if the printer is USB, TCP/IP or wireless. Additionally, printing remotely with Terminal Services or Citrix may not work with RDP-DOS. |
| NetMeeting or Remote Desktop |
To provide the highest level of support, RDP requires access to your system with Remote Desktop or Microsoft NetMeeting. Carbon Copy and other remote tools are not supported. See Hardware Requirements for more details. |
| RDPWin | RDPWin is our Microsoft .Net Windows-based software. It accesses the same database at the same time as your existing RDP-DOS and Internet Reservation Module (IRM). Please review: |
| For more information see Hardware Requirements. | |
| Home | RDPWin | RDP-DOS | IRM/IRM.Net | Open A Web Support Ticket |
|---|---|---|---|---|
|
Version 2.xxx | Upgrade to RDPWin | Link to Marketing Site | Contact Us |
| Training | Vendor Interfaces | Troubleshooting | RDP Sales Website |