Using Purge to shrink the database

When your database starts getting pretty large, you'll probably notice things slowing down.  In fact it can suddenly slow to a crawl if it starts reaching the limit of your computer's RAM, causing Windows to swap part of it out to disk.  

The obvious solution to this is to use the Purge function (under the Maintenance menu) to clear out old data.  However there's a bit of a catch -- if you're already slowing down, especially if you're hitting the RAM limit, then it will have a hard time purging because the purge function itself takes a lot of RAM (for queuing up all of the changes to be recorded in the log and possibly transmitting them over the network).  

Here are a few tips for purging:

First, make sure you have a good backup of your current data, which should be stored in a safe place (this is your business' historical data, so don't take it lightly).  The more backups the better, and don't be afraid to use the Restore function to test the backups.  You can use these backups later if necessary to look at older data (preferably on a different computer, so it doesn't risk affecting the live system).

When possible, start using the Purge function before you really need to.  For instance if you're still running fine after a few years, don't wait for it to slow down -- purge any data older than 2 years before it starts slowing down.

If you're networked, only use the Purge function on the Master workstation.  Make sure no other activity is necessary on any workstation (do it after hours).

Purge in small increments, starting from the earliest date.  For instance if you have transactions going back to January 2002, then start with a "purge before" date of March 2002 to only purge a few months, then run Purge again with a date of June 2002, then September 2002, etc.  This will help minimize the amount of RAM needed each time,  as well as the size of the updates sent to other workstations if you're networked.

Advanced notes for networking:

A long delay after each purge to synchronize the changes is normal (perhaps several minutes, depending on the network).  However if it has extreme trouble sending the changes to other workstations, even when purging in very small increments, then you may need to do the following: Close down all clients, finish the purging on the Master, then manually copy the new database to each client so it doesn't have to synchronize.

You may also want to delete the log file created on the day of purging, since this can cause it to take a long time starting up ("validating" from the large log file).  Look for the "PRKLOG" file in the same folder as the database, for the date of the purge.  It's safe to delete the log as long as you have sufficient database backups -- the clients will automatically do a "full database refresh" since they can't synchronize from the log file, so this is also an alternative to copying the database to each client (just be sure that each client is brought up separately and given time to receive the database refresh before starting the next client).