One of our programmers, Dean Jones, recently dealt with a technical support incident that demonstrated the need to understand how UAC interacts with the business applications we use. A client was seeing odd results where different Windows users would see different data, even though the software in question uses a single shared database for all users. The problem turned out to be the location of the data.
We support a wide range of software, but nearly all this software wants to store data somewhere. Sometimes data is stored in individual files, such as Word documents or CSV files. Other software interacts with large or small shared databases. In any case, the data needs to be written somewhere.
In comes User Account Control (UAC), which was introduced in Windows Vista and has been part of Windows since then. UAC has the effect of making administrator-level users into normal or restricted users for most daily activities. When an administrator needs to perform an action that requires administrator-level permissions, the administrator is prompted to allow the action. The action cannot be performed until the administrator reacts to the prompt. The purpose of this behavior is to protect the user from malware.
Two of the areas UAC protects are the “Program Files” and “Program Files (x86)” folders. Adding, modifying, or deleting files in these or any subfolders requires administrator-level privileges. This is the reason an extra prompt appears asking permission when software installers run.
Now we come back to the support incident. The software in question stores some data alongside the executables. When the software itself is installed in the “Program Files” or “Program Files (x86)” folder, the data is installed there as well. This causes a problem when the machine on which the software is installed is running UAC. UAC doesn’t want files in those folders to be modified without the user responding to a prompt. The architecture of the software doesn’t allow the prompt to appear. Because the software couldn’t write to the original database, it seemed to create a new, separate database in the user’s profile folder. (UAC doesn’t affect files in users’ own profiles.) As a result, different users were seeing different data.
It is important to become familiar with where your business applications store their data. If the software stores its data alongside its program files, UAC may interfere with the software’s operation. There are a couple of possible workarounds, although others may be possible:
- Install the software in a location other than the “Program Files” or “Program Files (x86)” folders. Often, the software’s folder is installed directly at the root of a drive.
- Disable UAC. This is not recommended because you lose the protection UAC provides.
Below are a few software packages that may need these workarounds:
- Sage 100 ERP (when using a ProvideX database)
- Vineyardsoft KnowledgeSync/Sage Alerts & Workflow (when using MS Access databases)
With each of these software packages, other options may be available to separate program and data storage. If you know of a way, please leave a comment. I’d like to know.