As you may have noticed, there are a number of files in ServiceDesk that need to be archived from time to time. Essentially, archiving is analogous to what happens in your file cabinet as one year ends and the next begins. If your office is like most, you probably have one or more drawers where, throughout the course of a year, you assemble all the various bank statements, paid bills, contracts you’ve entered, and so on. When a new year starts, you probably close out that old drawer and open a new one. Eventually, the contents of that older drawer will be moved to a box or boxes and stored in a dusty room somewhere. That, essentially, is archiving. The general idea is that you want to keep your current work area exactly that. Ancient records may occasionally need accessed, but the current area is made much less weighty (and accessible) if the ancient stuff is at least kept in a separate place.
It’s no different with several of the files that ServiceDesk uses, except we do the archiving process more often than once a year. A current area can be kept much lighter (i.e., less to look at, easier to find what you want, more instantaneous access by your computer, etc.) if old stuff is occasionally put elsewhere.
There are five primary contexts in which this process occurs in ServiceDesk.
Most obvious are the Callsheets. The Callsheet pages (how ever many you have going at a given time) are intended to reflect current work in managing calls, service inquiries, and so on. When a Callsheet has completed it’s purpose, it’s marked accordingly (either as having been the basis for creation of a ‘Job/Sale’, as ‘Otherwise Done’, or for ‘Delete’ status). Conceivably, we might have designed the system to instantly remove a Callsheet from the current area (and into the Archive for all but the last category) whenever it’s status is so changed. We did not, however, for removing an item from the Callsheet lineup changes the pagination of everything that comes after. It’s a significant event, and for such reason we thought it best for the process be done on an occasional, batch basis (i.e., letting multiple “done” items accumulate as work progresses, then periodically, and only when ready, removing all such items at once).
Similarly, the JobsCurrent file is intended to contain records pertaining only to jobs that are in-progress. We want completed jobs moved into the JobsArchived file. But that movement is a very serious event, because CstmrDbase indexes must be updated at the same time, copied to each station, and so on. Then there’s the ScheduleList, where again the intent is for the current file to contain only current appointments, and for appointments from the past to be regularly moved to archive. This event is not so significant in terms of what must be internally managed, yet by nature should be done on a batch basis, for it’s by the passing of a day that an entire set of appointments (those from the previous day) suddenly become ready for removal. Additionally, there’s your PartsProcess and AccountsReceivable files, where the same or similar considerations hold true.
As you’ve learned on previous reading, there are methods to manually invoke each of these various archive procedures, on an individual basis. Prior to Version 3.8, that’s exactly what we expected you to do, as often as might be deemed beneficial. In a typical operation (say one having five techs), we expected that Callsheets should probably be archived a few times each day (press Alt-R), the ScheduleList once at the beginning of each day, the JobsCurrent file at least once a week, and the PartsProcess and AccountsReceivable files perhaps once a month. The problem was, most users considered the duty of doing this something of a nuisance, and in fact often failed to invoke the procedures as often as they should have. So, we created a solution: the Auto-Archive utility.
Using the solution is simplicity itself. Simply “turn it on” from within the Settings form. Do this from whichever computer it is that you want to have performing the procedure (not from any others), and leave that computer turned on (with ServiceDesk running) overnight. At precisely 12:30 am Monday through Friday, the system on that computer will self-initiate archive procedures in each of the five files discussed. It will further copy updated CstmrDbase indexes to each of the other stations (for this purpose, obviously, you must leave them running also and connected in the network, but it does not matter if ServiceDesk is running on them at the time).
That’s all you’ve got to do. No fuss, no muss. With so little effort, all these files will be daily cleansed of old stuff, and your CstmrDbase indexes kept up-to-date. The only limitation is that, for Callsheets, a regular nightly archive may be less frequent than you want. If so, continue to manually invoke the procedure (for Callsheets only, the QuickKey is Alt-A) as often as wanted throughout the day (at least you’ll start with a freshly archived Callsheet work area in the morning, based on the automatic procedure having occurred overnight).
If, on the other hand, you’re against leaving your machines running overnight (as is needed for the Auto-Archive procedure to implement automatically), there is a “next-best thing” that allows you to turn your machines off overnight—while still keeping the burden of archiving minimal. Basically, you can manuallyinvoke the same meta-process that would have occurred, overnight, had you had the system setup for it. Under ‘File Functions’ in the MainMenu (there is no QuickKey for this), you’ll see an item labeled “Invoke Auto-Archive.” This features does, obviously, exactly what its name suggests. Specifically, it immediately invokes the same process that would have occurred automatically, overnight, had you had the system setup to do so.
If you do turn your machines off overnight, but will nevertheless make it a practice to religiously click on this item once each morning (before the rest of your work begins), you’ll have the same benefit as if using the full-auto system, and with scarcely more work. The primary downside is that, to fully keep your files fresh, you must force yourself to remember to do this each business day (whereas, with the full-auto system, there’s no such need).
A sixth context involves a kind of quasi-archiving. It’s in the FundsJournal (see page 178). The difference is that there we do not use two separate files (i.e., one for current data and a separate file for old). Instead, we use a moveable marker within a single file (called the “CurrentAreaPartition”). It’s purpose is to allow the system to know how far back, into the file, a search can be limited and still be certain of retrieving all non-checked entries. Like archiving in general, movement of this marker is an “event” –type procedure, because a significant search must be conducted to assure accuracy in the process. However, the system self-invites this process on detecting significant need (a quick check being made each time you load the Funds form). Of course, if you permit the procedure and yet have allowed old, non-checked entries to accumulate in the file, the system will be unable to move the CurrentAreaPartition forward. If so, it will inform you, and suggest that you amend the situation. Given such structure as this, we deemed it best not to include this particular, quasi-archiving procedure among those that are invoked automatically during the Auto-Archive process.
Actually (and in contrast to the other records here discussed), old AccountsReceivable entries are currently not saved in any separate file. Instead, the process simply deletes those entries that have been either paid or written off. We have never encountered a need to review such records in archived form (particularly since the ApplicationsJournal, see page 198, records payments received on any receivable). If you have such a need and would like the old records to be genuinely “archived” (rather than simply thrown out), please let us know.
You might notice that, with this automatic procedure added to a few others, your computers have a busy nighttime lineup of work to perform. At 12:00 am on any business day, the SD-Backup utility should run its procedure for the ‘daily’ category of backup (see page 233). At 12:30 am, there’s this Auto-Archiveprocedure. At 1:00 am, one of your stations should run the WipAlert procedure (see page 134), and at 1:30 am, perhaps another the WipAlert-Supervisor procedure (see page 170). Be sure to leave the applicable machines turned on, with ServiceDesk or SD-Backup running (as the case may be), so these procedures can indeed be run (unless, in the alternative, you want to manually invoke the auto-archive procedure after turning on the machines upon arriving in the morning, as described in text following).
If there are any stations in the network that do not receive updated copies (the station that does the Auto-Archive will be waiting, when you arrive in the morning, with a report regarding all copied updates), you’ll need to figure out why. For such purpose, well here explain the requirements that must be met in order for the archiving station to recognize and send copies to any other. (1) The other station must be running and connected in the network at the time the Auto-Archive procedure takes place (i.e., 12:30 am on the morning of any business day). (2) The other station must possess the appropriate “c:\sd\cstmrdbs” folder on its hard drive. (3) If ServiceDesk is running on that other station at 12:30 am, it must not be a version prior to 3.8. (4) From within Windows, the archiving station must have “mapped” the other stations hard drive with a local drive-letter designation (see page 338) you may confirm the last requirement by checking, from the archiving station, to see which drives are offered in the ‘FileServer’ designation box of the Settings form. All other stations, that you want to have copied with CstmrDbase updates, should be found there.
While opinions vary, there is a significant plurality of computer gurus who believe it is better for your computer’s health (particularly its hard drive) to be left running, at least most of the time, especially if it is actively used on a near daily basis. If you have its energy-saving options set appropriately (so that various functions “hibernate” after some period of non-use), the electrical draw from doing so is quite minimal. Plus, there are other tasks (automatic hard drive maintenance and so on) that can be facilitated much more conveniently if this is your practice.
Even so, there’s another potential use of this “manual-invoke” feature. It happens sometimes in our office that, though we intend to always let the full Auto-Archive function take care of us (thus we leave our machines running overnight, etc.), occasionally, we’ll inadvertently go home at night, having left without ServiceDesk running on the machine where the Auto-Archive feature is turned on. Thus, we arrive the next morning only to find the process was not done. No worry. Just click on ‘File Functions’ in the MainMenu, then on ‘Invoke Auto-Archive’, then watch as the procedure goes through its tasks—exactly as we’d intendedfor it to do overnight.
