In simple terms, a Peachtree archive is a “read only” snapshot, or copy, of your live database, as of the moment you create the archive.  In Premium and Quantum editions, the archive creation process can be run from directly within the software.  For Peachtree Complete, the user must “manually” create an archive outside of the application interface.

In Premium and Quantum, the “Archive Company” routine is available either from the File menu or as an option in the closing “wizard” when a year-end close is run.  The routine asks the user to give a name to the archive file (it defaults to a name which includes the current system date) when creating it. We recommend that you NOT accept this naming suggestion, but instead use something somewhat more descriptive, like “FY2010 before close”, or “pre-chart of accounts change”, or something that will help you find what you are looking for when you need to peek in the archives.

And the whole point of creating an archive is of course so you can return to it to look something up when needed. Let’s review how that works.

To open an archive, choose the File menu and select Open Archived Company.  Peachtree will then present you with a list of all of the archives that have been created for the particular live company from which you opened the list. If you are looking for an archive for a different Peachtree company, open that other live company first, then choose Open Archived Company.

The reason for this slightly confusing navigation scheme (for users with multiple Peachtree companies, anyway) is that the archives Peachtree creates are physically stored within the data folder that holds your live data, in a folder named “Archives”. You cannot choose where to create the archives, and when opening an archive you cannot choose what folder to look in. Peachtree will always and only look for an archive file to open from within the Archives folder within your company data folder.

Once you have opened a Peachtree archive, you can perform all of the normal lookup and  search functions, and run any reports for that company you may need for that particular time frame. The only thing you cannot do is change any of the data. The database and all of the tables within it are permanently stored in a “read only” state, removing the possibility of making changes to archival data (I good thing, in our opinion!).

Should you accidently move, damage, or destroy your archive database, you can restore it to its original location (so it can be opened) via the “Restore Archive” routine from the File menu. This will allow you to browse out to the location of the archive to be restored, and then restore it to the folder where Peachtree needs to house it in order to allow it to open.  It is important to note that this “restore archive” process does not restore the archive into your live data, or replace any live database. It only puts the archive file back where it belongs to make it usable again.

If you are using Peachtree Complete instead of Premium or Quantum, you will need to “manually” create your archive to replicate this product functionality. Basically, you will need to make a physical copy of your live database folder, give the copied folder a different name, and then change security settings on that copied database from within Peachtree to make the files “read only” for all users. This is definitely a “home brewed” solution, which does not offer all of the functionality of the Peachtree Premium and Quantum Archiving routine, but it does give you access to data and reports that would otherwise be inaccessible.

If you have questions or issues with creating and managing Peachtree database archives, give us a call at 610-941-2116 to see if we can help you figure out an archiving procedure that is right for your company.

Since the key words are inactive and closed, prior to purging it is very important to make all list data that is to be removed (customers, vendors, employees, chart of accounts, inventory items, etc.) “inactive”, and all transaction data that is to be removed “closed” prior to running a purge. Contrary to what many Peachtree users believe, running a year-end close does not remove any data from the system; it merely “tags” transactions as belonging to a “closed” fiscal year, and also puts them into “read only” mode, making further editing impossible.

This can be problematic in that records that are not “closed” prior to running the year end close are stuck in the database, unable to be purged because they are not “closed” and unable to be closed because they are not in an open fiscal year. In this unfortunate “Catch-22” the best recourse is frequently an outside data repair service that can use developer tools to remove the “stuck” records.

Once you have determined the set of records to be purged, we recommend that you define a “purge sequencing strategy” to determine discrete, limited sets of records to purge over multiple passes through the Peachtree database. This is particularly important if the number of journal row records in your database exceeds 250,000 (you can check this within Peachtree by going to Help | Customer Support and Service | File Statistics, and scrolling down in the “Number of Records” column to check the size of the “Jrnl Row” table).

Quantum users can efficiently process a considerably larger volume of journal row records, but even for Quantum users we recommend purging when the volume of records exceeds 750.000.

A typical “purge sequencing strategy” would first seek to identify any transaction records older than 12 to 24 months prior to the first day of the earliest open fiscal period. Thus if your earliest open fiscal period were January 2010, you would be looking for records older than 1/1/2009 (or 1/1/2008 if you want to keep more records available).

To determine the oldest records in your system, open the transaction screen into which you enter the largest number of records (sales offers, vendor invoices, purchase orders, etc.), and click on the “List” button on the toolbar. Change the drop-down filter so that it shows “All Transactions” and note the date of the earliest record displayed in the list. That is your oldest transaction.

Do this same date lookup for each transaction type for which you want to perform a purge. With this information, it should be possible to establish a “phased” approach to transaction purges. If your earliest transaction date is April of 1999 (perhaps when you initially installed Peachtree) you might want to set three (or four, depending on transaction volume) distinct date ranges for the purge within each transaction type. Thus your sequencing might look like this:

Once you have removed all of the transactions that are no longer needed in the system, one or more additional iterations of the purge routine can be made, to remove so-called “list records” (customers, vendors, etc.) that have been tagged as “inactive”. If there are no transactions attached to these inactive records, they will be quickly and easily removed from the database.

Two additional items to consider prior to initiating a purge:

1. Consider creating an “archive database” prior to purging, so that all of the data you are about to remove from the system can still be easily accessed, in read-only mode, from the archive database;
2. After each successful step in the overall purge sequence, make a Peachtree backup of the database. Thus if your purge fails for some reason after Step #5, you will not have to start all over again from step #1. Thus seems blatantly obvious, and yet is all too often ignored. Peachtree backups are fast and easy to perform, and once the full purge is completed all of those interim backup files can be safely deleted.

We have performed hundreds of purges for clients, and when followed carefully these steps will never fail to produce the desired results (sometimes with the aid of a few additional tricks we have learned over the years!). If you feel squeamish about running a purge yourself, give us a call at 610-941-2116 to discuss your database maintenance needs and request a fixed price quote.

Terminal Services has become a very popular vehicle for configuring remote computing environments, and most of the software applications we support at TriStar explicitly support Terminal Services. Peachtree is no exception to this. However, there are some very subtle but significant configuration settings which can seriously impact Peachtree’s performance in the terminal services environment. Emailing documents (via the Peachtree PDF Writer) is one of those areas.

Our client was consistently unable to email invoices through Peachtree when operating on the Terminal Server. The client was also experiencing periodic difficulties printing to her local printer when attempting to print to it through Terminal Services. Needless to say, this can get to be very annoying very quickly, and erode one’s confidence in the technology which allegedly facilitates this kind of remote access.

After much troubleshooting, we discovered that a somewhat obscure “group policy” setting in Windows Small Business Server 2008 was automatically “redirecting” any document sent to the My Documents folder on the Terminal Server over to the file server, which then ran afoul of the registry settings, or permissions, for Peachtree when attempting to email (or in some cases print) a Peachtree document.

Having diagnosed it, the fix was simple: turn off the group policy setting for this within Small Business Server. Voila! All Peachtree documents can now be emailed, and the sporadic printing issues have all disappeared.

If you are running on Small Business Server 2008 (or any other version of Server 2008 for that matter) check your “Group Policy” settings to make sure that you are not also an unwitting victim of “My Documents Redirection.”

Emailing invoices out of Peachtree is really very easy and convenient – but only if all of the technology is harnessed to work together.

Please let us know if you have also experienced emailing and printing issues in Terminal Server. We may be able to help you fix it.

 Two reasons.

 First, have you ever tried to restore a tape backup file to your server? Chances are this backup system was set up, and is periodically tested and maintained – hopefully! – by your IT person or firm. Chances are also that you don’t really have a clue how to restore a file yourself, or an entire directory, from your backup media, thus requiring you to chase down your IT support resource in the event you need to restore your Peachtree data. By the time that occurs you have either been “down” for longer than you can tolerate, or additional accounting data has been entered into the system, meaning more redundant entry when the database is finally restored.

I still recount a “horror story” from over fifteen years ago, when a client dutifully changed backup tapes every morning, took them off-site every night, and never made an application-based backup. One day they corrupted their database and needed to restore from tape, only to find that the tapes were all blank. No one had ever verified what was being backed up, or tested the restore process to insure its reliability.

 Application-based backups should not be considered as a replacement for an unattended server-based backup system, but as an adjunct to such a system. Server-based backups typically write their data to some type of external storage device, so that if the server drive fails (the most common type of server failure, by the way), your precious data is available to you “detached” from the server drive. It is, however, so much easier to restore an application-based backup file, since the program takes all of the “techno-babble” out of the restore process and guides you through the restore right from within the application.

These types of backups can of course also be stored on external media (thumb drives, USB drives, etc.) but will run much more slowly if directly backed up to an external device. Better to first back up to a local drive, then drag the completed application-based backup file to the external media for secure storage.

 Second, do you really remember – or have the time – to manually run a backup every day? Can you routinely get everybody out of the system, on your schedule, so that you can run the backup? Probably the answer to one or both of these questions is “no”. Peachtree’s automatic backup configuration can eliminate these roadblocks to protecting your valuable accounting data.

 To use the new Peachtree automatic backup feature you run a small “utility” (from within the application, off of the File menu) to specify:

• what company to back up,
• where to store the backup file,
• what credentials you have to permit access to the company database,
• what additional components you may want the backup to include,
• and what to do in the event that a backup file with the same name already exists.

You save these settings in a “configuration file” (one for each company whose backups you want to automate), and then invoke the Windows Scheduler application, which is typically installed on all Windows-based PC’s.

 Windows Scheduler then takes over the process, asking you how often the backup should run, and what time it should kick off. The “no-brainer” setting for this are “daily, in the middle of the night sometime”.  Just be sure that it can complete its backup before your server based-unattended backup starts up, as the one could conflict with the other and prevent a clean backup from either source.

 If you are not yet running on Peachtree 2010, you can still use Windows Scheduler, in conjunction with some old-fashioned “batch files”, to more or less accomplish the same automated backup routine.  Not a simple task, however. You can start a fire with a flint and some straw, as well, but lighters are a whole lot easier. And “easier” usually translates into actually getting the job done reliably and consistently.

When it comes to backing up accounting data, reliability and consistency are the values you are looking for.

 Give us a shout if you would like to learn more about automated backups for Peachtree.

 So, what is this mysterious critter that sits lurking quietly beneath the surface of Peachtree?

 In overly simple terms, it is what is called a “database manager”, storing the data that users enter into Peachtree and “managing” the process of “locating and serving” the right information to users based on their activities in Peachtree (and their security settings). Pervasive manages the byzantine process of updating the Journal Header, the Journal Row, the Customer, and the Item tables every time a user enters an invoice in Peachtree, making sure that all the data goes where it belongs and is properly indexed so it can be located again when needed.

 Pervasive SQL, unlike its more well-known “big brothers” such as Microsoft SQL, Oracle, and MySQL, is designed specifically as a “low cost of ownership” self-administering database manager, with no dedicated Database Administrator (DBA) required, and no real technical knowledge needed to initially install and configure the product. In fact, the Peachtree installation routine makes all of the Pervasive installation and configuration settings transparent. This is a good thing, to a point, and fits nicely with the pricing model and target audience for the Peachtree application.

 However, veteran computer users should recognize that there is no such thing as “one size fits all” when it comes to configuring a database. Some Peachtree users hit the database very lightly, while others process thousands of transactions in many different tables within the database. Hardware and other “environmental” configurations can be vastly different from company to company, which can have implications for performance, and therefore for database configuration. Sage has to account for all possible variations in uses when setting up default configuration settings.

 Because Sage Software has no way of knowing in advance exactly how you plan to use your Peachtree system, or what your transaction volume will be, the only logical response from Sage for initial database configuration is to make the settings conform to a “lowest common denominator”, which addresses the published minimum hardware and overall “technology environment” requirements. That is really the only way to go to insure that the product will work “out of the box.” Keep in mind, however, that the Pervasive SQL engine can only work with what is made available to it, via its configuration settings, and the minimum, automatically-set system configuration does not necessarily insure an optimum setup for your specific accounting software needs.

 So, what is a user to do to wring a bit more performance out of this powerful-but-low-maintenance-oriented database manager?

 There are four factors to consider in “tuning” your Peachtree setup. Three of these are relatively straightforward, are independent of the Pervasive database itself, and can be addressed by most competent IT professionals. The fourth factor involves “performance tuning” for the actual Pervasive PSQL engine on the server, and is a little more involved (including modifying Registry settings on the server, which makes some folks get sweaty palms right away – for good reason).

Server Hardware
Don’t have a dedicated server? Get one. Peachtree doesn’t need a dedicated server to operate, but if the performance of your accounting system is a concern of yours, start here. Using a so-called “peer to peer” network for running an accounting product requires acceptance of lots of performance concessions, which most users grow tired of pretty quickly. Servers today are more reasonably priced than they have ever been.

Look for at least a dual-core processor, around 3 Gigahertz or better. Pervasive does not take advantage of dual processors yet, but if you run other applications from the same server (as most small businesses do), using dual processors will allow the operating system itself to manage some of the “load balancing” between the various apps.

Purchase the fastest disk drives you can afford. Disk access time can make a huge performance difference for a heavily input-output intensive application such as accounting. A “Raid 0” stripe array, while pricey, will allow much faster disk writes than a more “conventional” disk setup. Your money or your time…..

Server Memory
Server RAM is not terribly expensive, and is relatively simple to install these days. The question of “how much” RAM to install can be complicated, and the answer is generally dependent of what apps will run on the server. Of course no one ever has good answers to all of these questions when purchasing a new server, so there are two rules of thumb here.

1. Never buy less than 4 Gb of RAM for a modern server.
2. Always ask your server vendor about memory “deals” (2-for-1, additional discounts for larger chipsets, etc. etc.) and then purchase the most memory you can afford within the confines of  that “deal”.

Windows servers have some limitation on how much memory a user can address, but having plenty of memory will insure that there is always more than enough left for other server purposes after the user has maxed out the user-addressable memory available.

Network Environment
Many apparent database performance issues are actually a consequence of the network “infrastructure”, and these can really be the devil to diagnose. There are a few obvious things to consider here.

1. Network interface cards (NICs), routers, and network switches are all critical components of the computing environment, and it rarely pays to “skimp” on those components. Purchase high quality components from known manufacturers, and have them configured by knowledgeable IT professionals.
2. Don’t have your network cabling installed by your brother’s nephew (unless he is a competent IT guy).
3. Don’t use a wi-fi connection for a large database; wi-fi is neither fast enough nor reliable enough (with microwave ovens, cell phones, etc. interfering) to trust for accounting transactions.

 Configuring the Peachtree Pervasive Database Engine
This is the fourth and final piece to focus on to “tune” your Peachtree install for optimum performance. I will address this final piece of the puzzle in my next post on PeachFuzz.

1.  Tweak your anti-virus settings – Most anti-virus software allows you to define “exclusions” to virus checking. You should “exclude” the folder where you installed Peachtree on your local drive, as well as the folder and all subfolders on the server where your Peachtree data is stored. This will not likely put your computer in harm’s way; we have not heard of any malicious software ever infecting a Peachtree .DAT file.
2. Free up local hard drive space – You should try to make sure that you have three times the size of your largest company database or 1 Gb, whichever is greater, available as free space on your local hard drive. If Peachtree needs to create a Windows “swap” file, this is where it will be parked. Running a “disk defrag” on the local drive to optimize the available storage space can also help in some situations.
3. Edit your Peachtree global settings – There is a section on the “General” tab under the Global Settings menu that allows you to set up “smart data entry” rules. While enabling these settings can be handy and make the system more convenient to use, they can also contribute negatively to performance. Unchecking all of the checkboxes in this area may improve speed.
4. Disable Events- This is an area of Peachtree that we find hardly anyone uses, but it may still be “activated” on your system. To turn this off (which can improve performance) click on Tasks, then Action Items, then click on the “Options” button on the Action Items menu bar. From the Options menu select the Transactions tab, and uncheck any of the boxes that are checked off in the “Create Event” column.
5. Avoid duplicate transaction reference numbers – Peachtree allows you to use the same “reference number” (e.g., vendor invoice #, cash receipt ID, etc.) as long as you do not use it for the same “master record” (vendor, customer, etc.). However, using the same number over and over (e.g., “cash” for all deposits) causes the application to work harder when searching and storing information. Keeping all of your “reference numbers” unique to the greatest extent possible can improve performance. It can also make life much more pleasant in the unhappy event that you ever need to export and re-import your data; the import will sometimes reject duplicate reference numbers.

 Of course the most significant contributor to system performance is the size of your Peachtree database, and within that database the single biggest contributor is the Journal Row (JRNLROW.DAT) table within the database. This table holds ALL of your Peachtree transactions, and each time you search for a transaction record the system needs to read through that entire table to find the requested record.

 So, how big can this file safely grow to before performance becomes an issue? There is no hard and fast rule for this (still more art than science), but our general “rule of thumb” is to begin thinking about maintenance to your database when the journal row table approaches 150,000 total records, if you are using any version of Peachtree except Quantum. The more powerful Quantum product can gracefully accommodate three to four times that number of records without causing significant performance “degradation”.

 You can review the record count for all of your Peachtree tables by selecting Help | Customer Support and Service | File Statistics from the top menu bar within Peachtree.

 Once you have determined the overall size of your Peachtree database and viewed the record counts for the individual tables, you can make a judgment about purging some data. Purging is the process of physically removing selected records from the system, to shrink the overall size of the database. It can, however,  be a time consuming and technically daunting task, since there are any number of “gotchas” that can impede or abort the purge process.

We have assembled a set of instructions for performing Peachtree database purges on our website, which you can review by clicking here. In some circumstances it is more cost-effective to use an outside data repair service to fully purge records that are no longer needed in the system. And in all cases, it is good practice to make an “archive” copy of the database before starting a purge. Peachtree Premium makes the archiving process easy, but Peachtree Complete users can create “manual” database archives.

 Carefully following these “best practices” for Peachtree data storage will help you to get maximum performance from your Peachtree software.

However, typing an entry into one of these “drop down” fields will add that entry to the drop down list automatically if it is not an entry already on the list. Most of the time this is what you want to do, but sometimes data gets into these fields that is clearly incorrect and doesn’t belong there. Problem is, once it’s on the list anybody can select it on a subsequent record entry and compound the error.

So, how do you get rid of these unwanted entries?

Cleaning this up is a two-step process, First, find all of the records that have the incorrect entry and edit all of those records to replace the field(s) with the correct entry; this can be done manually, or via a mass export/import (call us if you don’t know how to do this).

Next, once you are sure that no records are holding the values you want to remove, run a Peachtree Data Verification (File | Data Verification). Choose the option to run both tests, and choose to make a backup before running the tests (always back up before running any database maintenance task).

Under the Hood: The Data Verification process checks the values in the AFLOCAT.DAT table against all the values in all the records, and removes any values that are unused (e.g, mis-typed, mis-”cased”, etc.).

Once complete, those unwanted, unneeded choices will no longer appear in your drop-down lists.

Why should I bother to upgrade, my software runs just fine?  We offer two responses to clients who offer this all-too-familiar refrain.

First, Sage Software’s support policies provide end-user technical support for the “current” version of Peachtree and the prior two releases. Thus with the release of Peachtree 2010, Sage will shortly discontinue product support for any versions of Peachtree older than the 2008 edition. There are obvious revenue generation motivations for Sage to follow this course, but it also speaks to the difficulty of maintaining a support organization with expertise in many different product editions.  Software telephone support is not a long-term career choice for most aspiring technologists, so these positions inevitably turn over pretty rapidly. Chances are, after three years there are very few support technicians at Sage who have been exposed to a version of Peachtree that is more than three years old.  TriStar’s staff does not turn over, so we support any version of Peachtree in use, but our options are similarly limited if we need to turn to the “manufacturer” for product support on your behalf.

Second, Peachtree users who process payroll within Peachtree absolutely need to remain on a supported version of the product. When payroll tax tables change, payroll tax forms change, or more significantly, when payroll tax policy changes (forcing a change in the actual processing instructions) Sage will only make those changes to the product editions presently supported.  With health care reform, economic stimulus efforts, and a myriad of other “sea changes” emanating from Washington, it is very likely that “older” versions of the Peachtree software will not be capable of processing these changes.

So, the practical implications of this policy is that you need to upgrade your system no less frequently than every three years.  With the “life cycle” of computer hardware now acknowledged to be less than three years, there are often “technological imperatives” for upgrading your accounting software. Applications released more than three years ago (and likely designed well before that) are unlikely to behave flawlessly in a new operating system, on new computer hardware, that didn’t exist when the accounting application was originally designed.

Love it or hate it, responsible business owners should expect to upgrade their “business critical” software applications (of which accounting is certainly one) no less frequently than every three years.

So, how old is your accounting software?