Win 8: This app can't run on your PC

A somewhat strange and potentially misleading message can appear on the desktop of Windows 8 PC's:

This app can't run on your PC
(much less walk!)

Most users will probably know that "run" is the same as "execute" or "operate" or "invoke" or "launch."   So we do not quibble with that terminology per se.

Use of "app" is for those of us who have been developing software programs and software applications for decades is a little disconcerting, but is now the widely used lingo for anything and everything that runs on "smart technology" (whatever that is).  We would however never refer to our accounting software as an "app" no matter how hip that might be.  

But, besides use of the informal "can't" in the context of a relatively serious and disconcerting error message like this, our objection is that the problem could well relate to the fact that it is the operating system that cannot execute the program.  Thinking that it is the program's fault, or that of its software publisher, immediately leads to potentially errant conclusions, provoking the user to start reinstalling previously working programs in acts of futility, and making a bad problem worse.

If you receive a message like this the very first time you have ever tried to "run" a newly installed program under Windows 8, then, yes, it could relate to the fact that you have a 64-bit program trying to run under a 32-bit operating system version, or perhaps anti-virus software, user permissions or SmartScreen conspiring to block your program and not allow it to run, and potentially any number of other culprits.

But, if this message suddenly appears after programs have already been working (i.e. running), then in fact the problem could be the result of incomplete processing of Microsoft automatic updates (which is why we do NOT like to enable automatic updates).

The actual solution may be to return to a prior system restore point.   Or complete the unfinished updates.

This is all sounding eerily familiar.  Incomplete automatic update problems that lead to applications not being launchable is not a new problem.  We just have now a new unhelpful error message associated with that circumstance.

Another recent example of a problem caused by an automatic update that we wrote about:

Microsoft automatic security update causes font degradation

Problems associated with incomplete XP Pro updates were legendary.   The legend continues!

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: