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:

http://www.actian.com/products/operational-databases/psql/

FAQ's:

http://www.pervasive.com/database/home/products/psqlv12/v12FAQ.aspx

Download page:

http://www.pervasive.com/database/Home/Products/PSQLv12.aspx

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

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 http://windows.microsoft.com/en-us/messenger/messenger-to-skype), it is remarkable that problems with MSN messenger live.com 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 live.com 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 live.com 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 live.com account getting sometimes a "connection refused by server" response.

Investigating further, we finally stumbled on these helpful postings:

https://messengergeek.wordpress.com/2014/11/12/most-third-party-messenger-clients-have-gone-offline-temporarily/

and

https://messengergeek.wordpress.com/2014/12/05/microsoft-appears-to-be-pushing-messenger-to-http/

And also:

http://ismsndeadyet.com/

We tried linking a new live.com 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 bn1.gateway.messenger.live.com.  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 "live.com" 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 msn.messengergeek.com did not work for us on the 18th but as of the 19th was working again. But for how long this time?!

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:

Do you want to run this file?

Starting with XP Pro SP2, program and other files downloaded from the web from many of the more commonly used web browsers are individually flagged and subsequently carry a security warning when an attempt is made to open or run (execute) them.  While initially helpful, the warning may persist when flagged executables or equivalent are opened or run from a networked drive, which most users find to be annoying and unnecessary.   In an era where users are increasingly being bombarded by warnings and messages of all kinds, excessive warnings that users continually have to routinely bypass can then lead to users ignoring error messages of true importance.

When an executable file associated with the application is run from a local drive, users have the option to trust that specific application or even all content from a given publisher, and regardless of whether the UAC (User Account Control, applying to Vista and above) is enabled or not.

Open File- Security Warning example, executable downloaded via Internet Explorer 8, Win 7, run from local drive:

But the same is not true when running the same or a similar executable from across an internal network (i.e. the local intranet) .  The “Do you want to run this program?” message occurs in that case without end and without an option to not always ask this question before opening the given file which is available when running from a local drive.

Open File- Security Warning example, same executable downloaded via Internet Explorer 8, Win 7, run from network drive (note the lack of an option to not always "ask" before opening the file):

Do you really want Windows to be constantly asking you if you really, truly want to run a program that you launch every day across a network drive?

Most users do not need nor want the aggravation and annoyance of this yet additional warning message, particularly if they are running the program from an established desktop shortcut and even if the program is located on a non-local drive, since that is after all one of the purposes of a network drive.

Fortunately there are some options available to eliminate this security warning that carry little to no security threat.  (Always discuss the ramifications of changes to your system security with your IT support.)

While this issue can be dealt with by setting group policies (particularly on larger systems and/or those that have in-house IT support) or by trying to manually delete the zone identifiers that may be associated with the file, the approach we stumbled upon quite a few years ago and which is outlined below is typically the simplest and most effective.

From the Control Panel, proceed to Internet Options then click on the Security tab.   With XP Pro you will find Internet Options as a top level option.  With Windows 7 and Windows 8, first select Network and Internet and then  Internet Options.   (Note: you can also access Internet Options from within Internet Explorer itself.  Launch IE, click on Tools - or if you can't see the menu try ALT-F then Tools or ALT-T to go directly to Tools - then choose Internet Options at the end of the menu or just press O and finally click on the Security tab.  Yet another method is to run inetcpl.cpl.)

Click on the Security tab.   Then select/click on Local intranet.   Then click on the Sites button.  When the Local intranet screen appears, click on the Advanced button.

Under “Add this website to the zone:”  type in the drive mapped letter/path or UNC path to the network drive.  It can include the actual executable file; however, that is not important and the executable name will be stripped off.   Despite the reference to a “website” on this screen (the wording here referring to these local intranet paths solely as "websites" is wrong and confusing), what will be entered here is a locally shared network path on another networked PC.

We used to always uncheck the "Automatically detect intranet network" option and then also uncheck "Include all network paths" option; however, adding a "site" to the zone is supposed to take precedence over the general Local intranet settings. Sometimes we have found that in order for the security warning to go away we have nonetheless still had to uncheck the "Include all network paths" option.  So if your warning message persists after following the above, try making those additional changes.

Click on Add and in the "Websites" list box  you will see a reference such as the one above or with the server name, e.g. file://computername (where computername is the name of your in-house server or other PC with a shared drive that you want to add to this zone).   Click on Close and then OK on each of the prior forms/screens.

Repeat on each PC in your network.

You do not have to restart or re-boot for these settings to take place.  Exit out of Internet Options (or out of Internet Explorer if the changes are made there) and then try your desktop icon to see if the warning message is gone.

If the same executable file is replaced in the future by a downloaded file via a browser that attaches a zone identifier or is replaced by a file from somewhere else on your system that has an attached identifier, then even with the security options above in place and regardless of how the UAC has been set, the user will see a warning like the one below.

Open File- Security Warning example, same exact executable re-copied from a local drive where the "Always ask" had not been unchecked, or which had been re-downloaded via IE, with now local intranet settings referencing the PC mapped as drive S: in place:

This warning then is identical to an executable first run on a user's local drive and notice that now
the user will similarly be able to choose to open it in the future without the warning (but still with the ability to at least verify that is it from the same publisher but not much more).  This does not guarantee that the file is completely safe but that job is best left to other procedures and protocols.

A better solution than the above would be to allow end users to "trust" individual files including executables regardless of their location (and especially if the executable has been digitally signed and therefore involves a known/verified publisher) and then using file verification (such as a file hash which would need to take into account alternate data streams associated with the file) technology to detect changes in a file that could then trigger a new one-time warning (with more information about the nature of the changes that might be helpful) to appear should a change occur that a user with no additional privileges would be allowed to then stop from continuing to occur as in the last example above.   This could be set as a property of the icon by a user with administrative privileges, i.e. "trust this file."   This is also not a perfect solution but an approach of this nature in combination with other security software and related protocols and procedures would provide a better balance between security and ease of use.

Some additional technical details:  Zone identifiers are alternate data streams (ADS) which came into existence with Windows NT (first introduced in 1993) and are sometimes referred to as NTFS ("new technology file system") streams.  These allow the same exact file to be associated with more than a single data stream and only occur on NTFS drives. These additional data streams however are not readily viewable without special tools such as Microsoft's Streams (a Sysinternals utility) or now with the Windows PowerShell.  Unfortunately malware can also take advantage of these alternate data streams, but ADS features are built into systems that use NTFS and cannot be disabled.

Internet Zones discussed in the context of Internet Explorer 11:
http://technet.microsoft.com/en-us/library/dd346863.aspx

Security Zones:
http://technet.microsoft.com/en-us/library/dd361896.aspx

Note these definitions/discussion from the above:

Local intranet zone:  "The Local intranet zone includes all sites inside an organization's firewall (for computers connected to a local network). "

Include all network paths option:  "Include all network paths (UNCs). Network paths (for example, \\servername\sharename\file.txt) are typically used for local network content that should be included in the Local intranet zone. If some of your network paths should not be in the Local intranet zone, clear this check box and then use other means to designate the Local intranet zone membership. In certain Common Internet File System (CIFS) configurations, for example, it is possible for a network path to reference Internet content. "

Firefox browser: Firefox had an option in its about:config settings to remove zone information when files were downloaded in a number of older releases.  The setting which could be set to false was:

browser.download.saveZoneInformation 

However that has since been removed in the latest Firefox releases and can no longer be set.  Since January of 2014, Firefox only marks executable file types with a zone identifier indicating Internet origin.

Scanners: A free scanner that can detect otherwise invisible alternate data streams (you can also choose whether to show or ignore "safe" ADS content and you can also remove either kind including the safe type which triggers the "Do you want to run file?" message):

http://www.pointstone.com/products/ADS-Scanner/

There are other free scanners such as Microsoft's Streams:

http://technet.microsoft.com/en-us/sysinternals/bb897440

CryptoLocker ransomware: educate your e-mail users before it is too late

Ransomware is not new but in the past year has entered into an entirely new era with the advent of the CryptoLocker virus. Just in the last two days in different parts of the country two of our accounting software users have encountered this virus and it has created havoc. Neither paid any ransom but rather were able to thwart the virus by taking fast action; nonetheless it caused an interruption in business of these users along with technical support expenses, and considerable angst.

Once a system is infected, the virus spreads very quickly and easily jumps around and onto shared network drives. On one system it jumped to a server drive from a client PC that only had basic, non-administrative user rights and within less than two hours had copied its ransom notice files into every folder on that drive. So any PC (or other device) connected to your network server could spread it.

Additional morphs of CryptoLocker have also recently appeared.

Your anti-virus program may not be able to detect CryptoLocker or its morphs. Therefore, it is critical to focus on the education of your end users NOT to click on links or open e-mail attachments from unknown, untrusted or suspicious sources that may be disguised in any number of ways.

It is not clear whether the virus is able to encrypt files that are in active use; but it does not seem to discriminate in terms of what files it goes after. One user's first notification was when a simple JPEG file could not be loaded and was essentially corrupted by the virus.

General background information about the CryptoLocker trojan can be found on Wikipedia.

A Virus Bulletin Ltd. blog mentions a recent tool that may be able to provide the decryption phrase in some circumstances as a result of a joint effort between FireEye and Fox-IT (the PDF maker). See:

https://www.decryptcryptolocker.com/

Some further helpful technical details:

https://www.linkedin.com/today/post/article/20140219164446-19686690-cryptolocker-ransomware

As is discussed in greater detail in a related blog, lack of end user awareness of potential serious infections as a result of careless e-mail use is a significant part of the problem. And hackers know this.

Recovery requires an off-line backup that was made prior to the infection. So in addition to strongly reminding end users about e-mail and related dangers, revisiting your backup strategies is also in order.

Resolving “yourexecutable.exe” has stopped working: sometimes bigger is better

Early in the life cycle of the development of TAS Professional and Advanced Accounting 7.x, it seemed to us that it would be a good idea to compress our executable files primarily to reduce the download time of installation files, and subsequent updates involving those EXE's.   At the time, producing lean and mean EXE files also seemed virtuous and in the best interest of our users.

An unfortunate consequence of packing or compressing executable files (which is something very different than packing a data file via a rebuild or reindex and also in this context very different from other kinds of file compression), however, is that they can lead to being falsely identified by anti-virus programs as containing malware. And, when attempting to execute programs under these circumstances, the executable can be completely stopped dead in its tracks.

The process of decompressing an executable actually leads to it taking more computer memory when run, causes it to also initially run more slowly, and can create other performance bottlenecks. Counter-intuitively, the larger-sized files can therefore actually run faster (modern executable files are typically not completely read and placed into memory all at once, so even very large executable sizes usually lead to little to no loss in execution time even across a network). In our testing after removing compression, we found that they in fact did not run slower, and this solved the problem of potential false positives with respect to some third party anti-virus and related software.

So, in 2012, we abandoned the practice of compressing executable files.

If you receive a message like this and you in fact trust the source (and also inspect the properties of the underlying file,  and also conduct some on-line research), you could temporarily disable your anti-virus software to see if the “has stopped working” message is overcome (or, better, add the executable as an exclusion; your anti-virus software should - and in fact must - have the ability to add exceptions including telling it to not scan data files in order to improve performance and false positives that could lead to data loss, etc.).

In the case of our executable files, the best solution is to simply contact us for a replacement. The easiest way to accomplish this is to simply update to a more current version that contains the uncompressed executable.

Despite our wanting to shrink our executable files and provide smaller files to end users to decrease download times, in this case it turned out that bigger is better.

Pervasive/Btrieve status (error) code 20

Error code 20 is often experienced by end users. The cause depends in part on the Btrieve/Pervasive environment in which the software is running.

Btrieve 6.15 systems

In Btrieve 6.15 installations (which includes XP Pro, Windows 7, Windows 8 and corresponding server versions), a file open error such as one of the following may be encountered when first running a program.   Examples:

First ensure that the program can be run from the server/gateway PC (i.e. the PC on which the software is installed) when logged in as administrator.

If you do not receive this error code when logging in from the workstation as an administrator but you do get it when logged in from a different profile (but can “force” the program to work by manually first running Btrieve 6.15's microkernel engine w32mkde.exe), chances are that the user is a part of a standard or limited group on their local PC. The user will need to be placed into a power user/administrative group* on the local workstation to resolve.  Even if the user has full rights to the shared folder on the server, due to the legacy 32-bit nature of Btrieve 6.15 they must also have similar rights on their local PC.  One of the reasons for this is because Btrieve 6.15 places its registry entries under HKEY_LOCAL_MACHINE\Software.

*Power user or above was necessary with Win 2000 and XP Pro.  For Win 7 and above, users may have to be given local administrator privileges in addition to setting the icon properties to "run as administrator"  (see below) unless two default registry settings are changed:

In addition, absent being given administrator rights, on 32-bit PC's, the My Computer\HKEY_LOCAL_MACHINE\Software\Btrieve Technologies key should be made accessible to all users.  On 64-bit PC's, the key is instead located at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Btrieve Technologies.

Wow6432Node on a Windows 7 64-bit PC

Right click on the Btrieve Technologies branch, choose "Permissions" and set  Users/Everyone to have full control.

With these settings changed to permitted local application data paths and appropriate rights granted to the Btrieve Technologies registry key, then even with Windows 7,8 and 10, users can be placed in a power user group rather than administrative group and still invoke the engine as was possible with XP Pro.  The Addsum Btrieve 6.15 Setup program allows an end user to establish these settings in a more flexible way.

It should be kept in mind that Btrieve 6.15 was never tested on XP much less on Win 7 nor Win 8, etc.  so it is in one sense amazing that it continues to work at all.   If this however poses an unacceptable security risk to put the user in a power user group with respect to local PC rights, then the alternative is to update to an appropriate version of the newer Pervasive engines, and then local user privileges can be restricted as desired.

In establishing the appropriate Btrieve 6.15 settings in the first place on each PC where the software will run, on Windows 7 and 8 and equivalent systems it is essential that the workstation configuration programs including the BTRSETUP.EXE are “run as administrator.” On these systems it may also be necessary to change the icon that launches the software be set to “run as administrator” when launching software that uses the Btrieve 6.15 engine (see below) unless some of the default microkernel registry entries have been changed as discussed above (and which can be managed with the Addsum Btrieve 6.15 Setup utility.

If the error 20 instead occurs during software operation and not in the context of opening a file, another reason for this error message in 6.15 installations relates to inadequate user "delete" rights such that the user is unable to delete 6.15 LCK files; if the LCK files can be moved and the error 20 goes away, this indicates a user rights issue.

In rare situations, users have received error 65516 which also appears to be linked to a certain Btrieve DLL's no longer being present (for example if the 6.15 wbtrv32.dll installed in the application folder in the case of Btrieve 6.15 installations was inadvertently deleted or removed by some process or is prevented from being loaded).

Terminal services (RDP/Remote services) environments and Btrieve 6.15

Status code 20's have been widely reported when attempting to remotely access Btrieve 6.15 data via RDP.   Typically the first user can be made to work, as long as the application is run with elevated administrator privileges to resolve initial status code 20 issues, but the second user will then commonly receive a status code 20 until the first user exits the application (and after the w32mkde.exe process unloads itself from memory a short time later).  While tweaks to the Terminal Services registry and/or to the Btrieve 6.15 registry keys have been reported to allow more than single user access, a newer database engine is needed in a remote access situation involving multiple users not only to avoid giving users full administrative access but also to provide faster and more robust file handling, as well as to better interface with modern backup approaches, and since newer "Btrieve" engines have been designed with RDP in mind.  Therefore, the best approach is to upgrade the "Btrieve" component to a newer version.

Pervasive systems

When running Pervasive database engine environments, the error 20 can be returned if the Pervasive workgroup or other engine is running and the Btrieve 6.15 components exist in the application folder where the executable software (e.g. tp7runtime.exe) is being invoked (or they exist in the Windows path, which we never install to, or some other path available to the user).

The Pervasive engine and the Btrieve 6.15 engine cannot be active at the same time. They can exist or available on the same system, but both engines cannot be run concurrently from the same desktop.

To resolve, either all PC's should first be running the same Pervasive engine and the REMOVE615.EXE (provided by us) should be run to remove the Btrieve 6.15 components from the application path if the intent is to use the engine with the Advanced Accounting or other TAS-based software. If the Pervasive was installed as part of some other software, then a solution would include uninstalling the Pervasive workgroup engine if is not going to continue to be used (if related to a demo install for example) or to stop the Pervasive engine  (how that is accomplished depends on the Pervasive version; newer versions usually run as a service) before trying to run the application using Btrieve 6.15.

Incorrect or mismatched DLL's may also be the case of an error 20 in Pervasive environments.

New Wisconsin state withholding tax rates as of April 1, 2014

The state of Wisconsin implemented new state income tax withholding tax tables and rates to be implemented on/after April 1, 2014.

As is often the case, a change in a state's withholding tax rates often does not require an Advanced Accounting software update due to the ability of the end user to maintain standardized tables, particularly when a state follows an approach similar to that of the Internal Revenue Service's annualized rates and related formula structure.

Wisconsin is somewhat unique in providing two alternative annualized methods, referred to as Method A and Method B. The rates computed by these methods produce similar, but not exactly the same, withholding amounts. These calculations in turn will not exactly match, but will be close, to amounts listed in withholding tables for manual look-up.

Since at least 1988, Advanced Accounting has used Wisconsin's Method B approach since it most closely approximates the typical annualized schedule logic. And, as is also typical, there is a separate rate withholding schedule for employees that have a withholding status of “Single” versus “Married.”

The only piece of hard coded programming logic in Wisconsin’s formula involves a $22 amount per state exemption claimed that is deducted from the amounts computed by the standardized annualized tables (after which the calculated amount based on previously annualized wages is then de-annualized based on the number of days in the current pay period). We could also make that an end user managed value, but this $22 amount has been the same since at least 2004.

We also could have just as easily (and in fact initially did) use Method A to meet the April 1, 2014 changes for Wisconsin, but it would have involved using more internally hard coded logic compared to Method B, and would therefore make the system less flexible for future changes. So we have reverted those changes to again rely on a Method B withholding schedule structure.

Advanced Accounting users that have employees that are subject to Wisconsin state income tax withholding therefore only need to update the WIS (Wisconsin Single) and WIM (Wisconsin Married) tax codes in payroll (PR) module option K (Maintain Tax Tables) as outlined on page 45 of the Wisconsin Withholding Tax Guide Effective for Withholding Periods Beginning On or After April 1, 2014, Publication W-166 (1/14). 

For end user convenience, a link to a PDF that shows what these should look like from within the Advanced Accounting software is contained below.

Wisconsin PR-K WIS and WIM rates effective April 1, 2014

XP Users: The sky is not falling

With Microsoft retiring its official support for XP today, many users are in panic mode.  Users of XP however should not despair nor does immediate upgrade action need to be necessarily taken.   But, users should educate themselves on what this means going forward.

Some 20% to 30% of the worldwide Windows PC user base still uses some flavor of XP, typically XP Pro. It has been a good run, and XP Pro has been a reliable, relatively annoying-free operating system (and remains our favorite).

Behind the scenes, Microsoft will be continuing to update XP Pro for some customers privately, particularly in the financial sector.  If a critical update becomes obvious, it would be surprising if that is not released in some fashion to the general public, although one's strategy in going forward should not bank on that happening.

Upgrading a given PC from XP Pro to Windows 7 Pro typically isn't really feasible (and even less for a Windows 8 Pro transition).   It isn't just a matter of installing some update to an existing PC (or laptop) after which all of your currently installed programs will simply function in a way that you just go forward and never look back.

While we have no reservations about using Windows 7 Pro or Windows 8 Pro and/or corresponding server versions with our software generally, there can be various kinds of other compatibility issues, and since it effectively requires a full replacement of an existing PC (both in terms of likely hardware upgrades required, plus the PC running XP is likely old and not worth spending the time and money to refurbish it) , the cost of migrating software to a new PC is very high unless the end user runs very few software applications.   For some users, you could easily budget the true cost of a new PC to include some four to six hours of time per PC (minimum) PLUS the actual cost of the hardware, to make a migration.   For some PC /server migrations, it could take quite literally days to effect a full migration and that PC/server still would not contain everything that that the prior one did.  And even then, some third party application may not work and/or important information overlooked and lost.

Depending on end user and other software requirements, compliance with HIPAA or other industry specific standards, whether the software used most is on-premises or cloud-based, and depending on the compatibility of critical software used and equipment age, it may be best to simply plan on replacing PC's in connection with current retirement schedules, but not otherwise act right now simply because Microsoft has stopped providing security updates and not succumb to some of the scare tactics that are being circulated.

Exploits relating to the use of the Internet Explorer (IE) web browser have been known for a very long time and are not new.  While there are some government or financial web sites where you still might have to use IE to gain all functionality, it would be best to now restrict the use of IE (and even then, only if you have to use it) on updated Win 7/Win 8 PC's to the extent available (in a mixed network environment for example) and completely avoid using IE on your XP Pro PC's.  (Do not however attempt in any event to ever remove or uninstall IE from a PC running Windows!).

Automatic Windows updates have also often caused as many problems as they have purported to cure.  We are not suggesting never updating, but we have seen numerous problems with automatic updates.   This is something then that XP Pro users will no longer have to worry about!   We frankly do NOT recommend setting your computer system to automatically update for operating system related changes and updates; instead apply the updates when you can monitor their progress, and watch them being installed.   This will avoid many bad Mondays.

It will remain important to be vigilant about all PC use and to continue to update your browser and anti-virus software.   Opera, Mozilla Firefox and Google Chrome (at least until 2015) have all indicated that they will continue to support XP.   So, if you have not already done so, we would strongly suggest installing both the latest versions of Chrome and Firefox (because sometimes Chrome doesn't get the job done) on your PC's or laptops running XP Pro and keep them updated.  The same of course is true with anti-virus and malware software since most anti-virus software publishers (including Avast which we like) have indicated that they will continue to support XP Pro (in the case of Avast, for at least the next three years).

If you already have installations of Firefox or Chrome on your battle-proven XP Pro machine, make sure they are the latest versions (some older versions of Firefox for example do not support the latest XP Pro through SP3). 

Ensure also that you have anti-virus software in place that is being updated (but which is set with appropriate exclusions; it should not be scanning database files for example in real-time).   If you are using Microsoft Security Essentials, Microsoft says that they will continue to provide updates for a “limited time” after XP's official retirement to allow for a transition, so plan on disabling that and installing some other anti-virus program on impacted PC's in the very near future.

Continue to educate end users as to best practices and safe web surfing.  Continue to consider issues that relate to physical access as well as your firewall, and restricting what can and cannot be done on a given PC.   Continue to monitor the effectiveness of your data back-up strategies and ensure that they are actually made, and that you know how to restore files should that become necessary.

An overlooked security tip:  when your PC or laptop isn't being used for an extended period of time and all other things being equal, turn it off.  While there are certainly exceptions, most PC's do NOT need to be left on overnight.  Nor should they be unless needed for remote access or on-line back-up (they should even in that event be scheduled to shut off at some point during the night, other than perhaps the "server" which still needs to be periodically powered down).  And if you are going to be gone from the office for several hours during the day, why not turn your desktop PC off as well?

When upgrading your PC's, if you use Microsoft Terminal Services, consider replacing your in-house PC's not with yet more PC's, but rather with Winterms.  We cannot understand why that approach has never gained traction; it isn't appropriate necessarily for every user on your network, but would be a very effective approach for many in-house users and substantially reduce not only current and future costs but also increase security.   So the only upgrade path for your XP Pro device is not limited to moving to Win 7 or Win 8. 

The sky is not falling and many users will continue to make good use of their PC's running XP Pro for at least the next several years.    Early last year we assisted a user running a legacy version of our software on a Windows 98 PC.  Somehow they had survived running in that fashion since 1997.  The technology cycle continues to shorten and so we are not suggesting that users should continue using XP Pro longer than perhaps another year or two; but we will also not be surprised to encounter users still successfully and happily still running it many years from now.

Postscript:  A Microsoft security blog relating to the above that you should read if you have XP PC's and plan to stay on XP for a while is here.   Even though we don't agree with everything that is stated there, this may help you to arrive at own conclusions.  It is important to note that sometimes getting the latest and greatest updates, especially when they are relatively new, is not hardly any guarantee of better protection.  An example is the so-called Heartbleed bug.  It was only the newer released OpenSSL DLL's that had the issue.  DLL's released in 2011 for example did not have the problem. Again, we are not suggesting never updating nor keeping current up to a point, but that was in essence a two-year old bug that only just recently came to light and it was the newer updates that caused the problem, and it simply speaks to the fact that the overall security of your system involves far greater issues often than just whether or not you can obtain automatic updates.  Sometimes being on the bleeding edge isn't so great and exposes you to greater risk.  Yet, this is rarely discussed or written about.

A pertinent April 21, 2014 avast! blog:  So you’re sticking to Windows XP? Here’s how to protect yourself: It’s the end of Microsoft support, not the end of the world.

Looking up Pervasive (including "Btrieve") status codes

How do you know what  a given Btrieve/Pervasive file open error means?

Advanced Accounting and TAS Premier/Professional programming language-based applications most typically use the Btrieve/Pervasive database manager (sometimes referred to as the "record manager" or "database engine") implemented in various configurations.   Traditionally the "Btrieve" product has been an engine interface to an application rather than a database management system.   Newer versions do now have the availability of a user interface layer making it closer to a DBMS rather than solely a record manager as in days past.

The trademark "Btrieve" is no doubt derived from the term B-tree coined by Rudolph Bayer and E.M. McCreight in 1972 relating to a tree database structure used for indexing (finding) binary data.  The origination of the term B-tree in turn perhaps might have been formed as a different kind of  "binary tree" although they are not synonymous.  (Perhaps the "B" related to primary author "Bayer" and tree for the related data "tree" structure; the authors did not indicate why they chose the term B-tree in their 1972 article.)   The methodology employed by the Btrieve microkernel engine for database indices, and which also became the industry standard, is B-tree searching.  

At one time Btrieve software was owned by Novell, but that has not been the case now for a very long time. Many other software applications also use Btrieve or more commonly in today's world, Pervasive.SQL.  (Peachtree accounting software for example uses it but its installations limit its functionality and it does not provide the user layer interface nor all of the utilities and management tools.)   The  term "Btrieve" is still used informally when discussing status codes and database engine issues.

Btrieve/Pervasive database engines remain a robust, cost-effective option for data intensive software applications.   They have the ability to scale from a single user to hundreds of users and, in an on-premises environment, rival Microsoft SQL in terms of performance as well but usually at far less cost.

When the Btrieve/Pervasive database manager encounters a problem, typically a "status code" number is returned (historically returning a one to three digit number, and later expanded to four; SQL errors can be up to five numeric characters).   There are therefore many  potential responses.

When a status code is returned that involves a  specific data file error/status code, it is then very important to investigate and resolve; the application should not continue to be used until that occurs.   In the case of a status code 2, for example, when a program tries to open or save to a given data file, that status code means that an I/O error has occurred and that  the data file must be repaired (often simply reindexed, but not always) before any further "writes" are attempted.  In other words, it must be given immediate attention.   The "2" error will persist and not go away with continued use and usually never indicates a temporary problem of any kind.

Users are plagued with warnings and error messages responses from the operating system, anti-virus programs, other programs, etc. and quickly become anesthetized to this constant barrage of messages.  This has become much worse with newer versions of Windows and the infamous UAC (user account control) which excessively tends to burden the user with its constant questions and messages.   This then tends to lead a user down a road of simply ignoring error messages that do not stop the application dead in its tracks.

But in the case of a status code such as a 2 in the case of Btrieve/Pervasive applications, it should not be treated like a "check engine" light but more like a flat tire:  you need to pull over and stop! 

Understandably, end users typically are not aware of this, they may continue to try to continue to use the program and create even more problems requiring manual repair efforts.

(And as an aside with respect to status code 2, our May 11, 1998 tech support memo which in turn reprinted  an article posted in a CompuServe Btrieve form circa 1995 still applies when troubleshooting that error code!)

In the days of Btrieve 5.x (16-bit engine) and prior, there was no built-in way to determine what a status code might mean.  That continued to be the case with the 32-bit Btrieve 6.15.   Starting with newer versions of Btrieve after 6.x (called now Pervasive), documentation started to be included that contained this information (in addition to on-line sources including the Pervasive web site), but it still requires some digging to find.

CD's shipped by Pervasive for example include reference libraries and PDF's that provide various levels of useful information including status code details.   But, it is usually simplest to lookup the status code from Pervasive-installed programs.

So where do you find them?

It depends on the version in use.   In the latest versions (10 and 11),  they are available directly from the Pervasive Control Center under Help and then PSQL Documentation Libary, i.e.:

Pervasive --> PSQL 11 --> Control Center & Documentation --> Help

Once the PCC is loaded, click on Help then PSQL Documentation Library:

You can then search the status codes:

Absent a Windows program/start menu in Win 2012 Server and Win 8, search for Control Center in Win 2012 Server and Win 8).    If you just search for Pervasive, you will not find it.

In earlier versions, such as version 9, they are available from the Function Executor utility provided by Pervasive (that end users typically will otherwise have no need for, and will not even be aware that it exists) which is nested deeply from the Windows programs menu:

Pervasive --> Pervasive.SQL --> Other utilities --> Function Executor -->Help

Click on Status Codes to proceed to investigate the error/status code.

Power outage leads to Pervasive 3106 and 3012 status code (error) messages

A multi-user Advanced Accounting customer today reported that they could no longer "get into the software" following a power outage.

The user has a Pervasive client-server version on a system that we have long supported.

From a client PC, the user reported receiving a Pervasive 3106 status code. When we logged into a server (but not the “main” server” where the Pervasive engine is located) and running terminal services via remote desktop, we received a status code 3012 when trying to launch the accounting software, when it tried to open the first “Btrieve” data file which in this case was at the logon screen.  (The software will initially launch without a Btrieve/Pervasive engine present since other files are first opened that do not require it.)

From the Pervasive documentation, causes of the 3106 and 3012 status codes are:

3106: The Pervasive Network Services Layer encountered a connection failure.

The Pervasive Network Services Layer was able to establish a transport connection at the client side, but the connection attempt at the target side failed.

One of the listed possible causes of a 3106 status code is:

The MicroKernel is not running on the server.

3012: Local engine is not accessible to the MicroKernel router.

Access to the local engine is not possible because it is not loaded or could not be launched. You can receive this status code if you try to access a local file on a client and you do not have a Workgroup engine installed or if you try to access a local file on a server and the Server engine is not running.

When the server re-booted following the power outage, the Pervasive service had failed to automatically start and was indeed not running.   Normally, Pervasive services are set to automatically load on start up.  The client Pervasive services were running (either the client PC's didn't lose power or they started up normally on re-boot) but the main server engine was not, and so the initial cause of the 3106 and 3012 was not as obvious as in a situation where no services or engine was available at all.

Restarting the Pervasive service on the server resolved the issue.

Postscipt:  In October of 2017, a user reported a situation where a client PC in a Pervasive workstation engine configuration suddenly receiving a file error 3106 when trying to load Advanced Accounting across their network. Their troubleshooting revealed that a recent McAfee anti-virus update had blocked previously open ports causing the Pervasive engine to no longer be able to communicate with the gateway PC/server as before.  Pervasive uses by default port 3351 for its transactional engine and port 1583 for SQL/ODBC access (these ports can be reconfigured but rarely are).  In the case of Advanced Accounting, or any Btrieve-based software, if port 3351 is blocked then the Btrieve interface communications will be blocked.   

Telnet can be used to determine if the server/gateway PC or local PC is listening on port 3351 as follows:

telnet computername 3351

where  computername is the name of the server/gateway or the local PC.   On each PC of interest:

netstat -an

will show what ports are listening.    Because the output will scroll by quickly, scroll the file by either adding a more option:

netstat -an | more

or redirect the results to text and and view in notepad, e.g.:

netstat -an > results.txt

notepad results.txt

In the results of that command you should open ports such as:

  TCP    0.0.0.0:80             0.0.0.0:0              LISTENING
  TCP    0.0.0.0:1583           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:3351           0.0.0.0:0              LISTENING

Running Advanced Accounting from a Mac (or iPad)

Advanced Accounting is designed to natively run from Microsoft operating systems.  We normally only provide support therefore for the software running on a Microsoft server or workstation/desktop operating system.

For quite some time now, a Mac or iPad could still though access the software using a remote desktkop equivalent application (or app in the case of an iPad).

With the recent introduction of  OS X Mavericks there are now more options.

An Advanced Accounting 7i user recently tested running the accounting software with Parallels 9 running Windows 8.1 and OS X Mavericks and has reported that it works flawlessly.

The Advanced Accounting software in this case exists on a Windows-based server.  Parallels was installed on a Mac Book Pro which then allows you to install Windows 8.1 as a virtual machine.   One desktop can then be run with OS X Mavericks and a second with Windows 8.1 simultaneously.    In the Windows 8.1 desktop,  Pervasive engine can be installed, and Advanced Accounting 7i ran apparently just as efficiently as if run on a Windows client in this configuration.    There is also a Coherence mode that can run Windows programs directly on the Mac desktop, and this also reportedly ran perfectly.

(Thanks to Andrew Sawitoski for providing this information.)

Windows 7 or Windows 8?

Frequently we are asked this question.   Either one is fine.   If you are using a legacy version, however,  see the "special considerations for legacy versions" section below.

Most importantly, make sure that you obtain at least the "Professional" version of these operating systems and preferably nothing lower (i.e. for business/networking purposes you want to normally void "Basic" and "Home" versions).

Ideally all PC's would simply come with the so-called "professional" versions.

Because of the touch screen interface and the fact that even with the program menu having returned in Windows 8, corporate users are still commonly choosing Windows 7 over Windows 8, and for most users, that remains a reasonable/safe/efficient choice.

Despite some its awkward tile and other interface issues, Windows 8 does seem to be very solid in terms of reliability and memory handling.    A number of our users are using Windows 2012 Server which  uses the "Windows 8" interface.   Heavy desktop users will still likely prefer Windows 7.

Special considerations for legacy versions:  

If you are using a 16-bit legacy version such as Advanced Accounting 5.1 or prior, or software based on TAS Professional 5.1 or prior then you need to be aware that unless you have the 32-bit version of Windows 7 or Windows 8 pre-installed (instead the 64-bit version will likely be pre-installed), you will not be able to run the software without going through extra hoops and may also have networking limitations if you plan to use your legacy version in a multi-user or multi-device (shared resources) environment.

Your system type (32-bit or 64-bit) can be determined by checking your system information properties.

Even if you have a 64-bit system type, it is still possible to run 16-bit legacy program.

Windows 7 Professional and higher:  install the the XP mode. See Install and use Windows XP Mode in Windows 7.

Home versions (64-bit Vista, Win 7 or Win 8):  One option would be to run the legacy programs under a virtual machine such as http://www.vmware.com/products/player/.

With Windows 8 Pro or higher, the included Hyper-V is available to run via a virtual machine.  See http://windows.microsoft.com/en-us/windows-8/hyper-v-run-virtual-machines.

A few more references for legacy users:

64-bit versions of Windows do not support 16-bit components

Windows 8 Program Compatibility Assistant

Normally the best answer for legacy accounting software users is to upgrade their 16-bit version to the latest version of Advanced Accounting, and we will install and convert all of your data (everything moves forward and nothing is lost) for you remotely at no additional cost beyond the cost of the software update.

Network path not found

Recently one of our accounting software users suddenly could not run Advanced Accounting 7i from a local, shared path and received this message.  The details of the Windows error message indicated the error code 0x80070035.

The user was running Windows 7 Home (and had another Windows 7 PC on their network).  The software had been working the previous day when we were also on their system.   And it was not a Monday . . .

(A disproportionate number of computer problems happen on Monday mornings, probably due to weekend operating system updates, or networks not having been fully or properly shutdown, or power problems caused by storms, etc.; we otherwise like to blame them on sunspots which are for some reason more prevalent on Mondays!  The best strategy for dealing with these is to turn off everything that won't be used before leaving your office, and especially on Fridays.)

A UNC path was being used to reference the folder name in the format:

\\PCName\Adv\

Where Adv was the share name (in this case Adv61).    We verified the computer name was indeed the same name as the "PCName" (not the actual name) in the UNC path.   The folder was still shared.  The desktop icon properties were correct.  The INI file used by the executable and default registry entries were also correct.

And the operating system's network settings were seemingly all correct as well.   Network discovery for example was enabled (for a discussion of that setting, see Microsoft's enable or disable network discovery topic).

The causes of the "network path not found" error can be many but in this case it turned out to be Windows services that had been turned off.  We found for example that the TCP/IP NetBIOS Helper Service (and some others) had been stopped.  This isn't something that the end user had done so what caused these services to stop wasn't apparent.

Modern computer networks typically do not use NetBIOS (formerly referred to as NetBEUI).   It is a protocol that when using, for example, the Pervasive SQL engine is turned off (along with IPX/SPX) to enhance performance.   It can however still be used in simple file and print sharing networks (and the unfortunate "home" versions released by Microsoft)  and provide name resolution services as apparently was the case here.  

Other things that have been reported to cause this error include Windows firewall settings, anti-virus software, network name issues, UAC (may need to disable),  date/time clocks that are out-of-synch, and network card properties.   Services besides TCP/IP NetBIOS Helper Service to check to see if they are running include Computer Browser, Server, Workstation and if working remotely, Remote Registry Service and Remote Procedure Call.   (And we found also some of these services that were not running in this case.)  Power outages and power management settings could also be factors to consider.

PC networking has really not become simpler over the years.