The staying power of a 25-year old application development system

While we extensively used the TAS 3.0 system released in the late 1980's by Business Tools, Inc.  (the second printing of the manual was in March 1989, and which reached its prime in about 1991) back in that same era, in recent years we have had little reason to use it except in rare situations involving converting data from very old systems.    TAS 3.0's short dates were not Y2K compliant and most TAS 3.0 users had migrated their applications forward to newer versions long before the year 2000 for many reasons besides just the date issue.

Yet some users persisted, especially those that were highly customized and also for some that did not want to deal with changes that the Business Tools TAS 4.0 development system brought to the picture in 1993.

Users of some of these older systems (who chose to fight rather than switch) survived the year 2000 by customizing their systems to use "long dates."   A conceptually simple change, it nonetheless required making dictionary changes to every file descriptor (similar to a "table"),  changing every temporary defined date field to a long date size, then going through every data input screen and report form layout to make placement changes in order to fit the long dates and replace them with the newly permanent field and temporary field changed sizes,  and recompiling every affected program.  In short, a significant amount of work.

Both TAS 3.0 and 4.0 (and also 5.0 and 5.1) were 16-bit programs, yet they continued to run on every operating system that Microsoft came out with.  They survived the Win 95 "scare."  Then Win 98. Then NT. They kept on running on XP Pro (in fact, XP Pro was and is an extremely stable and reliable environment for these systems) after another scare that 16-bit programs were not going to function.  And they still will run innately on 32-bit Windows 7 including some very old components.

Nonetheless and despite the fact that TAS (and products written in TAS including Advanced Accounting) have long since been migrated into graphical, 32-bit worlds, we have found ourselves in 2015 consulting with several users who have extensive customized systems running on modern operating systems:  one case using TAS 3.0 (see screen shot below), and another that until very recently was still using a system developed with TAS 4.0.   And we have recently we have had to make some programming changes into these environments.  With the 3.0 system, we are making bug fixes to customized source code involving EDT source files (but not using the built-in TAS 3.0 editor) on an ongoing basis,  and with the 4.0 system dealing with converting the older program code to the newer TAS Premier 7i.

TAS 3.0 components still running on a modern system on a multi-user basis (May 7, 2015)

Predecessor products were actually released long before in the early 1980's, so the TAS development system has it roots that now go back well over 30 years.

And, even in 2015, rarely a day goes by where we don't still use in some context the TAS Professional 5.1 development system (first released by Business Tools, Inc. in August of 1996).

The longevity of these systems is truly remarkable, and largely unprecedented in the computer software industry.

Printing to a file in Advanced Accounting

The form that a user interfaces with in choosing where a print job should be sent is what Microsoft Windows refers to as a print dialog box.  It is not really a box but a small modal form that loads on top of your current screen or form.

Print dialog boxes server a similar function in different programs, but they can differ greatly in appearance and functionality from one software program or system to another.

In Advanced Accounting (or programs written using the TAS Premier development platform), a print dialog box is triggered after a user selects something to print.  In Advanced Accounting this is done by either by (1) clicking on the printer icon in a report preview in the upper left hand corner of the screen, or (2) immediately after clicking on a Print button with the print preview unchecked.  Either of those two things causes a "print dialog box" form or screen to appear.

Normally at this point a user would simply click on OK to print if their default printer name appears in the upper drop down, and after making any other desired selections.

Instead  of printing to a printer, however,  an Advanced Accounting user can instead redirect the printing output to a file as below from the print dialog box:

What is critical above is to know exactly where you have saved the file so that if you are wanting to attach it to an e-mail, you will know where to look for it (or if directed to an XLS file type, where to open it from your spreadsheet program).




More information:

Windows Print Dialog Box

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.

Microsoft automatic security update causes font degradation

Microsoft kernel mode driver security update 3013455 released on February 10, 2015 has caused the quality of text to degrade or fonts to become corrupt on some systems.   Systems impacted include Windows Server 2003 SP2, Server 2008 SP2 and Vista SP2.   There is an independent report that XP may also be affected.

Users with automatic updates enabled will likely already have this update.

The solution is to uninstall the update from the control panel (add/remove programs).    If you have enabled automatic updates, this update will still attempted to be installed, so if you have an afflicted system, you will have to start to control which updates are installed and avoid installing this one until/unless Microsoft finds a resolution (as of February 13 that was still not the case).

A site providing early information about the problem:

http://windowsitpro.com/msrc/patch-tuesday-font-corruption-kb3013455

Microsoft's description of the security update:

https://support.microsoft.com/kb/3013455

One report indicated that only the Courier New font was impacted, but in fact, Arial and other fonts have also been impacted by this update.   As of early morning on February 11, 2015, one of our users running Windows 2003 SP2 reported experiencing this issue.   It did not make their system unusable, but it caused text to be significantly less readable (all characters lighter overall, each character with broken connecting lines and not evenly rounded).    The same user had the problem recur 24 hours later because of having automatic updates enabled.

In a Terminal Services environment, users logging into an afflicted server via remote desktop (RDP) may experience the problem, whereas directly connected user clients that either do not have the update or are running a non-impacted operating system may not experience the issue.

You can determine what Windows updates may be installed on your system by clicking on Start and then choose Search.  Search for Windows Update.   When Windows Update is found, click on Stop.   There is a WindowsUpdate.log file than can be browsed and towards the end might show:


WindowsUpdate.log example:

2015-02-10 15:13:46:843  828 3848 Agent   *   Title = Security Update for Windows Server 2003 (KB3013455)

To fully review your update history, click on Windows Update in the search list and then click on the Review your update history option which might then look as follows:

Addsum Btrieve 6.15 setup utility updated and now available to third parties

Since 2004, we have provided a utility to assist end users in configuring the Btrieve 6.15 microkernel record manager engine in the context of providing support to end users of Advanced Accounting and TAS Professional originally released by Business Tools, Inc.  Business Tools had an unlimited distribution license for the Btrieve 6.15 engine.

Recently we have made additional enhancements to the utility which previously had not been changed since 2013 after periodic updates since its initial release by us.   This update will be made available to our accounting software in a future release.  We are now making the utility available for any third party use (since the configuration utility is not specific to any particular application).

A screen shot of the latest version of our setup utility as of end of January 2015 is contained below.

The latest version of the utility has been tested under XP Pro, Windows 7, Windows 8 and equivalent server versions, i.e. 2003 Server, 2008 Server and 2012 Server.

The Btrieve 6.15 setup utility can be acquired for a nominal amount at:

http://www.addsuminc.com/btr615setup.html


Background information: 

The Btrieve 6.15 engine was published by Btrieve Technologies, Inc. (later Pervasive and now Actian Pervasive).  It has not been updated nor supported by Pervasive since 1999.  This engine however continues to be operational under all 32-bit and 64-bit operating systems released by Microsoft since that time.

Btrieve 6.15 is a very compact workgroup engine that employs page locking (similar in terms of functionality to Microsoft Access, although it typically outperforms MS Access).   Many software publishers have over the users distributed applications using the Btrieve record manager engine.   Peachtree for many years for example included Btrieve 6.15 with their accounting software installations.

The Btrieve 6.15 engine did not dynamically establish its settings as did the later versions renamed to be Pervasive.   Therefore a utility that established those settings especially in a multi-user enviroment is needed.

Business Tools provided a barebones tool named BTRVINSTL.EXE with the initial release of TAS Professional 6.  This tool however did not establish all of the appropriate settings that were needed and that became apparent only after several years of end user support, and after further research on our part in migrating users from older versions of Business Tools software.   This then led to the development of our own tool, BTRSETUP.EXE, the earliest version of which was released only to users we supported in 2004.

Because the Btrieve 6.15 engine was designed to read values from HKEY_LOCAL_MACHINE, a local user needs more user rights than ordinarily might be desirable.  This was less of a problem in earlier eras where security rights were somewhat less of an issue than they are today.  With the newer security features added first with Vista and continuing with Windows 7 and Windows 8, some default and other settings that were provided by the original publisher of the Btrieve 6.15 engine are now in conflict and will even prevent the software from loading.   (In that regard, see also our related blog post entitled Pervasive/Btrieve status (error) code 20).   Our utility as now also recently updated can help prevent or solve some of those types of problems.   More technical information is contained on the btr615setup.html page referenced above.