Pitfalls of online or live database backup

The proliferation of online, cloud-based backup systems ranging from the extensively advertised Carbonite to CrashPlan, Mozy, Backblaze, and many others has led to their widespread and sometimes indiscriminate use.  When it comes to the backup of critical business data (such as your accounting software or other in-house database-oriented software), these online or "live" approaches should solely be viewed as supplemental to other traditional approaches and not as a substitute for them.

Further it is essential for most users that database files be backed up on a scheduled, after hours basis and not while they are in active use, i.e. your data files should not be simply getting backed up constantly as they change (except for in the most high end, life and death environments).

Why?

Live, non-scheduled backup will likely ultimately create file locking problems (especially in multi-user, but also in standalone/singler-user, database environments) causing your software to not function properly leading then to delays and support costs to resolve.  And these types of problems have been widely reported with many different systems.

Examples:

An older report from 2011:
How Carbonite is Kryptonite for Sage ACT!

Live backups not recommended Atrex database  (2013)
Carbonite Online Backups

Reported with Peachtree (Btrieve/Pervasive) and QuickBooks (2014)
Carbonite Locking Files

We have also seen Btrieve/Pervasive status code 46 problems (in both Btrieve 6.15 and Pervasive 9 and above) in connection with supporting Advanced Accounting as well as TAS Premier/Professional custom systems created by the use particularly of Carbonite (and also by attempts to copy files in other ways while data files were in active use) on a non-scheduled basis.  A status code 46 ("access to file denied") leads to software not being able to write to the afflicted data file causing a loss of data that then has to be fixed manually.

A practical reason to not backup your database "live" relates to extreme slowdowns that can sometimes be created in a live environment.  The constant backup of your data will create delays that could create other types of record problems, and your system's overall performance will suffer.

Online backup system software makers typically offer a "Home" as well as "Business" version.  The more costly (and often much more awkward to use) business versions would at a minimum be required to backup a multi-user database on a real-time basis.   Even with the higher end versions in place, however, this would not ensure that a backup with full integrity was being achieved.   With Pervasive systems for example, a system would need to be placed in "continuous operations" mode to ensure a full backup with integrity regardless of the backup method used in situations where the database files might be changing during the course of the backup.   For most users, the best and easiest solution is to perform scheduled backups when the database system is not changing (and in the case of Pervasive systems, some users even "stop" the Pervasive service to ensure that is the case, which is not necessarily recommended, but is a possible approach).

Strong recommendation (applies to most users):  continue to use non-cloud based, traditional backup procedures, and consider your cloud-based backup as simply an additional, supplemental method.  Ideally backup files/systems after hours or when your system is not in use with respect to all backup approaches.  Make local ("on premises") backup copies that involve non-proprietary methods (such as the copy and ZIP method provided in Advanced Accounting or in backup software such as Second Copy).


24-7 environments:

In 24-7 situations, it is likely that you can still find a "low use" time for the cloud-based backup to run on a scheduled basis.

Or:

(1) Exclude the cloud-based backup from backing up the accounting software or business data folder(s)  so that those files are never backed up in real-time;

(2) Assign an office/administrative person to oversee and/or perform a traditional backup (using the backup feature of the software or a batch/script file or process provided by locally installed backup software such as Second Copy) at a regular daily time that is communicated to all staff members.  In most cases, a full local backup performed directly from the server or gateway PC directly of just a software's data files can be accomplished in well less than 15 minutes.   Rotate backup medium (e.g. flash drive) and do not use the same media (or backup folder) every time.  Periodically take one of the backups off-site and rotate those.

In Pervasive environments, place the data files into continuous ops mode (there are several ways to accomplish this and it can be automated) before any backups are initiated if the data files can potentially change while being backed up during the scheduled backup (applies regardless of backup method).

Multiple copies woes with HP laser printers

Printing multiple copies of the same document (without having to first print it and then copy it on a different machine, e.g. on a copier) or "mopying" has been a Microsoft Windows printing feature since at least version 3.1.  This ability has carried over into more modern versions of Windows.

Advanced Accounting 7i printer dialog box

In early 1997, HP released the HP LaserJet 5SI Mopier which was a network printer that provided users with both a copier and a printer, and which produced multiple original prints (mopies).  Then newly developed HP technology allowed the transmission of a single document which was stored on a large internal hard drive (it was a large unit overall) from which the additional copies were printed.

This technology was refined over the years to provide a "Mopier Mode" in lower end printers that stored the document to printer memory.  But the base 2300/4200/4300 series printers did not include this memory.   Without either the hard drive or additional printer memory, the base model printers were  unable to "store the job" and would print a single copy if the Mopier Mode was enabled regardless of the number specified; only by disabling Mopier Mode was the driver (and the therefore the Windows printing subsystem) allowed to again handle the print job as it otherwise normally does.

Computer users have increasingly struggled with this issue with a broad range of HP printers from the lower end 1022, 1200, 1200, 2035 and 2430 models up into the 4000 and 5000 series printers. This increasing problem seems to be tied to this mode having become a default setting with newer HP drivers (for reasons that are unclear; it is not something that the majority of end users need, nor does their printing hardware often support it).   This means that the "Number of copies" in the printer dialog box may then either be not visible or may be grayed out at the time of printing. Even if changed in printing preferences, only a single copy will be sent to the printer as long as Mopier Mode is enabled as explained above.

To regain control of this setting at the printer dialog level and for those printers that have it, disabling Mopier Mode may be the answer.  This option, if available, should be in the Device Settings tab of the printer's properties (accessible via standard Windows Settings under Printers and Faxes).

Example of Mopier Mode location, if it exists, for a given printer

Other causes of multiple copy printing woes could relate to collating (try unchecking if checked) or anything that relates to job storage, document storage or any settings relating to mopying.

This issue is largely unrelated to operating system type as computer users have reported problems in connection with trying to print multiple copies with HP laser printers in association with a long list of MS operating systems including 2000, XP, Vista, Windows 7 and Windows 8.

Auto build when transferring a quote

Bill of materials (BOM) is a standard module included within the integrated Advanced Accounting software.   In addition to generating a build  of a finished or assembled product type from within the BOM module, the software has also long supported an "auto[matic] build" feature from within sales order entry whereby a build could be initiated right at the point of entering a line item.   For items that may involve little or no assembly such as kits that may have already been packaged (or that can be quickly assembled as part of the shipping process) but not yet formally built in the accounting system, this provides a quick and easy way to create units on hand that then can be reserved via the sales order module, and placed on a sales order for very fast order processing.

Recently a customer who is a heavy user of the BOM module and who also most commonly builds most of its items from "auto builds" (when entering sales orders) also wanted the ability to initiate a build right at the point of transferring a quote from a sales order.   This capability now exists and will be available in future releases.   This ability is also sometimes referred to as "building on the fly."

Just as when auto building from a sales order line, when building at the point of transferring a quote, the user has the ability to print a build order, and when building, the actual amounts used can be adjusted. 

While adding this capability into the quotes module might have on the surface seemed simple in just moving existing sales order entry logic into the quote transfer program, in fact it turned out to be extremely complex due to the many subtle differences.   The primary reason for the additional complexity relates to the fact that the auto build is being initiated in a very different overall place since the user is not interacting with a single line item entry when transferring a quote, and the decision logic that then occurs has many non-obvious implications.

Further the user may at first to decide to build, but then either not build all of the units or build a lower number.   And there are different circumstances involving whether the full quantity can be built or a smaller number (or none at all).

In addition to the logic issues involving when transferring a quote and in the extensive testing that we conducted over a month's time, we added a capability that the availability logic had never supported:  the ability to tell the user how many units of an item could be built  if all of the units being ordered could not be built.   We found this necessary just to be able to more quickly determine whether logic changes were working; and it should be highly beneficial to all BOM module users.

Another issue related to the fact that the user needed much more "messaging" information. When prompted about building an a item in sales order entry, the user would know exactly what item the message was referring to since they were working with it on-screen.   This is not true however when transferring an entire quote to a sales order where the user is not directly at that point interacting with line items and the line items normally do not even need to be displayed.

Advanced Accounting is multi-location driven in terms of its inventory unit processing.  Builds therefore occur at a "location" (which can simply a "blank" location or a named location; if necessary items can be separately transferred from one location to another when the finished item is being built).   When all of the units cannot be built at the time of sales order entry or when being transferred to a quote, the user will now receive the prompt:

"Would you like to determine what the maximum number of units are that can be built at this location?"

If responded to in the affirmative, then the program will make that determination and then allow the user to build that quantity (with the remainder, if all or some successuflly built, being placed on backorder).

The "auto build" flag, as in sales order entry, is also a trigger for initiating a build from a quote.  Users who never want to auto build therefore can specify that they do not want to be prompted to build in this fashion if desired.   This option is established in BM-I  Set configuration.   Items that are not available as units on hand at the location will then simply be placed on the sales order as units on backorder.

The new "maximum number that can be built" calculation functionality will benefit both the "auto build" and normal build/unbuild processes alike:

Auto build, i.e. builds initiated from:

SO-A Enter/Change Sales Orders (which can also be reached in other ways)

QC-B Transfer Quotes (which can also be initiated after saving a quote)

All builds:

BM-E  Print To-Build order

BM-F  Build/un-build process

Many users make heavy use of Advanced Accounting's BOM or BM module (and therefore ultimately BM-F).  Consequently, the BM-F build program has received considerable attention by us over the years.  We have been making programming updates to the standard BOM build/unbuild program since 1997 (after working with its earlier incarnations from the early 90's in even older versions).  In 2007 we first converted it to a graphical (true Windows form-based) program.  Extensive changes were made in 2009 to deal with negative unit and average costing problems that prior attempts had not fully resolved, and those efforts have proven to be quite successful.   In 2013, the entire recursive logic routine was re-examined and ultimately significant changes made to solve a resource allocation problem with builds deeper than two or three levels (builds can be up to nine levels deep) and a large amount of testing occurred with an end user's data involving complex  and deeply nested assemblies.  In the process of the 2013 work, significant user status bar information tracking each step in the build process was added since it was essential for troubleshooting, and that work remains in the program as a helpful aid for both us and the end user.

*The JC (job cost), BOM (bill of material) and POS (point of sale) were originally add-on modules starting with version 4.03 and in later versions 5.0, 5.1, 6.0, 6.1 and currently 7i included as standard.