Addsum web site and general info

Postings here will focus mainly on Advanced Accounting software updates, tips, and related topics. They will also include general comments relating to troubleshooting PC/Windows/network problems and may also include reference to our other software products and projects including any of our various utilities, or to the TAS Premier programming language. We considered setting up separate blogs for different topics so that users/others could subscribe to topics mostly aligned with their interests, but decided that it would be better to keep things simple since some topics cross over into others. We would nonetheless welcome your feedback/input in this regard. Our web site URL is Call us at 800-648-6258 or 801-277-9240. We also maintain so that older Business Tools users in particular have a greater chance to find us.


We highly recommend that accounting software users "follow" this blog via e-mail (enter your address and click on Submit below) or subscribe to a feed (see also below) as a way to keep current on the latest updates and accounting software news and information. You may also want to whitelist this e-mail address:

Follow by e-mail

Wednesday, December 24, 2014

Actian releases Pervasive 12: first look

The latest version of Pervasive (informally "Btrieve") was released on or about December 17, 2014.

Btrieve/Pervasive record manager engines have been the data interface backbone of choice for both Advanced Accounting (and earlier "Books") as well as versions of the TAS 4GL integrated development environment since the late 1980's. A number of other accounting software and multi-user database systems also continue to rely on the speed and robustness provided by these engines, a key feature of which has been expandability and true client-server support.

Version 11 was released in September of 2010 and remains in widespread use.

Important note:  Pervasive v12 will no longer support XP Pro nor Windows 2003 Server.

Actian now owns Pervasive and here is their product availability notice:


Download page:

Hardware requirements are the same for both versions 11 and 12.

It is expected that product support and updates for version 11 will continue until June 30, 2015.

There is currently no rush for existing users to migrate to version 12.  It will primarily be of interest for new users, users who are on older versions and especially pre-v10 systems who will now likely want to migrate to v12 rather than v11, and users who need to expand their license counts.

One feature of the new version is an interesting defragmenter that can be run while the files are open (see screen shot at end).

Other currently outlined features may be of little to no benefit for existing v11 users.

First look:

As an initial test, we installed the workgroup engine on a desktop Windows 7 PC (32-bit O/S, SP1) and also on an ASUS Transformer Book running Windows 8.1 (32-bit version).     Both installations went very smoothly, and with no issues.  The workgroup engine can be installed as an application or as a service.  Most users will want to install as a service.  We installed one as a service, and one as an application.

In both cases (and has been our experience with essentially all prior Pervasive installations since version 7), both PC's had to be re-booted before our test applications would run (the installation does not tell the end user however that a re-boot is necessary, but this is something we have routinely advised).    After re-booting and after some initial testing with two completely different applications running on each of the PC's, they both appear to be working exactly as expected and as they have with prior versions of Pervasive/Btrieve.

On one of the test PC's, we noticed something different than in the past:  the presence of an older Btrieve 6.15 engine in the application folder did not create a problem with the Pervasive 12 engine running.  And in fact, we were able to run one application using Pervasive v12 and another application using Btrieve 6.15 at the same time.  This previously has not been possible.

The installation default group now is Actian PSQL 12 rather than Pervasive.

Installed Pervasive tools such as the License Administrator, Gateway Locator and Rebuild look substantially similar as does the Pervasive Control Center (PCC).  User data files will not have to be rebuilt, and the "highest" Pervasive internal file format remains at 9.5 as it has since the Pervasive 9.x series.

Unfortunately Pervasive v12 continues to by default enable limiting data file sizes to 2GB before they "segment" which was a limitation imposed by Windows NT but which has not been an issue in newer Windows operating systems.  Segmented data files cause various potential problems including how multi-company file naming extensions are deployed within TAS-based systems as well as can create potential backup, data integrity, reindex,  manual file deletion/renaming and other file handling issues, and therefore is not supported.   Pervasive users will need to uncheck this option so that segmentation never occurs (and this needs to be done in the event of a re-installation as well).

 Pervasive v12 - uncheck Limit segment size to 2GB
(same action needs to be taken prior versions)

And, all supported protocols continue to be enabled by default in version 12.  Most users only need TCP/IP and non-used protocols should be removed by unchecking them (see below).

Pervasive v12 - removed unneeded communication protocols
(same as in prior versions)

Some final random thoughts:

We would be hopeful that the addition of the defragmenter feature might also mean that status code 46 problems resulting from access of the files from outside of Pervasive's handling might also be reduced or eliminated, but we suspect it will not.  The defragmenter however may prove to be a very useful diagnostics and general analysis tool.

With server version purchases, Actian is offering for free (but as a separate download) its "Actian Analytics Platform for PSQL."   This in part shows the influence of the new product owner and future directions that the product might take.  This tool looks interesting as well, but is not something we have yet looked at.

The installer update which automatically detects the bitness of client operating systems could backfire if installation and connectivity problems related to the 64-bit Pervasive client engine continues to occur with 64-bit client operating systems.   With v11, users have had more success installing 32-bit clients on client-server systems even if the server install was 64-bit and even though the clients are running 64-bit operating systems.   If this remains the case and there is no way to install 32-bit components on a 64-bit PC, then this will be a potential problem.

The legacy 32-bit Btrieve 6.15 continues to work for older users who already had this engine on even Windows 8 systems (32-bit and 64-bit).   Compatibility issues with this old version (despite its limitations, and despite not having been officially supported by Pervasive since the late 1990's) remains far fewer than with any subsequent version.  And contrary to what might have been published elsewhere, it does run on 64-bit Windows 7 or Windows 8.   It is not however suited for more than a relatively few simultaneous uses and does not provide client-server support, and it requires higher local user privileges than the newer engine.  Its tiny footprint and its ability to "keep on ticking" however is quite admirable.

In any event, it appears that Pervasive v12 should be a smooth migration for prior Pervasive users; and for new users, preliminary indications are that it is a solid product.

New PSQL12 Defragmenter tool

Tuesday, December 16, 2014

MSN messenger service going the way of the Dodo

Since the April 2013 retirement of  MSN messenger, also referred to as the Microsoft Messenger or as the Windows Live messenger (see announcement at, it is remarkable that problems with MSN messenger accounts have not occurred in a more widespread fashion sooner than now.

But sometime just in the past ten days or so, we noticed that our account was no longer connecting via Zoho Chat.   We thought that maybe something had changed there or that we had installed something that was preventing the connection.  In Zoho Chat, it simply attempts to connect with the message 'Connecting . . . ' which remains on screen indefinitely with no error message or any indication as to what the issue is, nor any indication of a sign-in failure.

We had no difficulties logging into which simply accesses browser-based mail.   We tried disabling/enabling the Zoho Chat settings with no change.

Proceeding to reinstall the latest version of a desktop instant messaging (IM) client we used to use, Pidgin, we still could not connect to the account getting sometimes a "connection refused by server" response.

Investigating further, we finally stumbled on these helpful postings:


And also:

We tried linking a new account using WLM protocol (instead of MSN protocol, and after installing the "msn-pecan" protocol - see first link above for the link and as recommended there) and that did not work, but then noticed the more recent indication that the HTTP method had to also be used.   That also did not seem to work;  we then changed the Server setting per one of the other recommendations to  The connection still did not at first seem to work, but shortly thereafter, and only after all of the foregoing changes, and for perhaps what will last for only a short period of time, we appear to have our "" connection temporarily back (which we have used solely to communicate with a single customer that historically has used it)!

The MSN messenger service does appear to be on life support.

Postcript:  the day following, a connection via Pidgin could again not be established.  In the intervening period,  Microsoft made a change that required HTTPS that Pidgin does not currently support.  More details.

For connectivity with Pidgin, changing the server (with or without the HTTP method checked) to did not work for us on the 18th but as of the 19th was working again. But for how long this time?!

Wednesday, December 3, 2014

Avast's Browser Cleanup/Firefox nightmare bug fixed

Avast has finally fixed its disastrous Browser Cleanup/Firefox add-ons bug.

When your anti-virus software works against you in a manner almost as destructive as the worst virus, it is a reminder of how dangerous software updates can sometimes be, and also how  new and inadequately tested software features can lead to disaster.

As early as June of 2014 avast! users were reporting a serious problem with the Browser Cleanup (BCU) option and Firefox.   Avast was aware of the reports but could not find a problem with their code.  The reports however kept coming in.   Unfortunately, we were one of the victims in September of 2014 after many other reports had been filed.  And more came after.

Not until November 17, 2014 did Avast finally find a solution and fix the problem which was not announced in the relevant forum until November 24 in which the Avast representative posted:

"Reason was a bug in the BCU which slipped through QA because it happened in some rare conditions only.  After the first reports from our customer it took us quite some time to reproduce and fix the problem."

As a software developer, we certainly understand the problem of needing to reproduce an issue in order to be able to fix it.  In this case however it wasn't a single customer, but many.   And the consequences were dire:  the Browser Cleanup literally went completely rogue when told to cleanup Firefox add-ons within at least a fair number of PC systems (and was not limited to a particular operating system) under some set of conditions, and due to the bug would proceed to delete thousands of local files seemingly indiscriminately in a fashion that can only be likened to a destructive virus.   In our case it reported two never used add-ons as having bad reputations; we did not need them, but made the mistake of telling Browser Cleanup to remove them.  A problem like this was so severe that Avast should have escalated the reports to the highest priority and remoted into systems that were having the issue in order to duplicate and resolve it.

In our case it removed a Delphi 7 program files subdirectory and subfolders completely involving some 5,877 files. It removed Winamp.  It removed Firefox.  It somehow removed avast! itself with 19 small BIN files marked as read only remaining.  It removed CrashPlan.  It removed OpenOffice.  It removed Malwarebytes.  And more.  And these details were reported to Avast.  And it would have removed even more had we not realized something was wrong and shut down the PC.  ("Removed" is intended here to mean deleted.  Folder names remained but files within those folders were all or mostly gone.)  Fortunately the Windows system folders were not impacted.

We were able to recover the missing files but only after hours of work.   The PC thankfully was soon again operational after a day or so of high stress, but there was still no response to our forum posting and no resolution for users.  And others have not been as lucky.

For Avast to blame their QA (Quality Assurance) testers for missing this problem is patently unfair.  Any code that could have had ANY chance of being as malicious as this was should have been foreseen by any experienced programmer.   Whenever you are DELETING local files from a user's system and are using some sort of recursive logic as must have been the case here in view of how the BCU bug was behaving (when the problem was triggered, the removal tool was clearly jumping around the local subdirectory structure of the end user's PC and literally ravaging their local file system) and this should have been caught by the programming staff in the first place.  The blame here must be placed at the source:  the programmer(s).

Programmers have the responsibility to substantially test their programs and not expect their QA departments (or end users) to catch them to the greatest extent possible.  They should also safeguard potentially dangerous code that might otherwise not be capable of easily testing, and/or that a tester might not be aware of.

One commenter indicated that since the users involved were using the "free" version that their expectations should be accordingly low, and tried to shift the blame to users utilizing the free version.  Wrong.  If the software missed reporting a potential virus (none of the anti-virus packages ever detect everything) that might be one thing.   But users do have a right to expect that even free software from a supposedly trusted source will not devastate their system, and clearly Avast is very much culpable in this regard.   Their software, free or not, was never authorized by the end user to delete local files beyond the Firefox add-ons.  Their free software is offering to protect, not harm, an end user system.  Viruses are also free but most users do not intentionally install them.  So here the very software that is being promoted as helping you to protect your PC instead becomes your worst nightmare.   And their BCU likely was behaving the same way with respect to Firefox (under some undisclosed conditions), whether paid for or used as part of the free version.   So this issue of free vs. not free is moot.

And to reiterate:  our PC was never infected with a virus or with malware of any kind other than the avast! Browser Cleanup software, a newer option we don't ever plan to use again and which was enabled by default, and is was one a suite of new things added to the product that is hard to categorize as something desirable or needed.  Its assessment of things that have a "bad reputation" is also certainly questionable.

Some screen shots below show some of the sequence of the initial reports of the problem and the ultimate posting indicating that in fact the problem had been tracked down and resolved by Avast are contained below.

End user beware.

Clips from the avast! user forum relating to this topic: