Larry Speaks Out on AccessDB
Excerpts from email FAQs on the Imperative to Retire Access
LARRY AULTMAN EMAILS: 12/12/2018: TITLE – Ten Gotchas - AccessDB will NOT run in Windows 10
Today we inform all U.S. AccessDB users of some absolute show stoppers for desktop apps in Windows 10 and Windows 2016 Server. The largest offender is Microsoft Access in sheer numbers.
Just a little Windows 10 background. All executable code must be “managed” code to prevent all the old issues of Windows XP (buffer overruns). All Windows 10 apps runs in isolated memory, even old apps. Old apps fail if they try to reach outside of the isolated memory. Windows 10 is built to be a virtual server. That means your apps on your device are treated the same way a cloud server virtualizes apps. Old apps are not designed for virtualization. The reason old apps can run in a virtual environment is that a dedicated environment is carved out of the virtual space. This completely defeats the purpose of cloud computing which is, standard environments to allow unlimited scale. You actually lose performance when taking legacy to cloud by adding more layers of management.
Here are 10 gotchas for starters, any one of which will stop Access dead on Windows 10.
1. Windows Global Assembly Cache. Windows 10 installs apps on a per user basis in isolated storage. Not globally. Old applications expect to install in the global assembly as was the standard until Windows 10
2. COM/Interop “features” has very limited support only in managed code and DDE (dynamic data exchange) is not allowed at all (the way Office apps use to let you drag/drop data).
3. Applications were required to use Strong-name assemblies to allow applications to use versioned assemblies does not work Windows 10 UWP applications as it does not support this old technology. This is a real killer of Access with components (aka controls or OCX controls.)
4. Cloud and virtual servers do not allow Global Assembly Cache installations and .NET likely does not even exist on the machine at all in cloud.
5. Cloud servers do not have a Global Assembly Cache because it is not compatible with cloud virtual scale.
6. Access in cloud virtual environment is not supported on Window 10 virtual machines for the above reasons.
7. Access user controls use COM/Interop to communicate with the OS and app (OCX controls) are not guaranteed to function as expected. Some features fail silently.
8. WMI and machine driver calls were allowed in older system are not supported in Windows 10. This is especially bad in Access that allows VBA to call into the Windows OS by registering an assembly during runtime. It fails only when the code is encountered and catastrophically when it does hit the code.
9. Access and other Windows desktop software are able to call user developed or third-party native C++ (unmanaged code) and will not load in Windows 10 or will fail when trying to call into managed code. This is very much like number 8 above, except even less predictable as it is generally localized to particular machines.
10. Windows 10 apps require digital signatures.
Access can fail at any time for no apparent reason. Usually it fails immediately when a system service changes (patch or update). More difficult is diagnosing a server policy change. A policy change can happen even when there are no patches or code changes making it difficult to understand.
Access and its cousins were built/licensed for a Windows computer environment on a single machine. It was never meant or licensed for virtual servers. For example, imagine a system with 5,000 virtuals on 100 rack servers. For Access to work, it would have to be installed on all 5000 servers, a huge management nightmare. The cost of 5,000 licenses would be astronomical!
Email 12/13/2018 TITLE - Using an XP virtual machine to run your Access DB? Yes, this works . . . BUT
So the customer decides to use an XP virtual machine and try to run the Access database in the XP VM. It does work, I use this method as a step in the conversion process to get all the data and forms out of the existing app. I do this on an isolated network with NO Internet!!
The problem with this as a solution to the Access problem, it is even less secure and less compliant that it was before.
1. XP virtuals are totally non-compliant.
2. Any authenticated person on the network can connect to the VM. If a user is working in the VM and a second user decides to login, the first user is bumped off and the existing session is taken over by the second user, leaving everything up and running.
3. The Access DB has now experienced a home invasion and has been totally highjacked because . . .
4. XP does not check your credential except at login. When the bump happens, the VM Host just swaps connections so XP never even knows the swap occurred.
Email 12/13/2018 TITLE: Big Butts - Yes, Virginia, it does run in Windows 10 . . . but
This discussion is about Access 2016, completely ignoring the restrictions and issues that Windows 10 imposes in other tech/data areas.
So, the other day an old-timer put me to the test, “I have Microsoft Access 2016 64-bit, and it opens and runs one my Window 10 computer. So, what is the problem?” Yep, that is a tough question. It does in fact run. My answer is simple, it might be OK for you IF your use of Access limited to these conditions:
7. 1. You are an administrator on your machine (can install software and run with elevated privileges)
2. Used only on your own personal Windows 10 device (compliance)
3. You are the only user of the database and it is installed directly on your computer (compliance and security issue)
4. You are not connecting to any other external database on a server somewhere (security issue)
5. You are not using it for storing any data that is HIPAA, PCI, or data that might be at risk like information about children or employees (compliance and security)
6. You have purchased and installed other software to provide security for Access
7. You have no plans to use it in the future on any other device that is not an X86 or X64 AMD/Intel processor architecture aka. PC
8. You are willing to allow your Access version to fail after the OS is upgraded under your Windows 10 license agreement (you become responsible for your app maintenance)
Access is really TWO parts. Access 2016 is a Windows desktop APP. Access database is a machine runtime driver that must be installed on the computer. For Access database, this is machine (device) wide (BYOD), anybody can use it. So immediately it has issues.
Access has gone back to 1995, it is a single machine Personal Computer simple database. Since 2007 Microsoft has systematically removed features that were added for enterprise environments. There are much better solutions for customers in enterprise or Internet connected environments. These new solutions do not suffer from the compliance and limitations imposed by Access and applications like it. That makes them more reliable. There are tons of reasons IT Pros, CIOs, and information security managers don’t allow Access on the corporate network, in the end its cost. It simply costs too much to force it to comply to the environment.
So, what about the literally millions of existing Access apps and databases that were built since 1995 and 2013. Intact has a ready-made solution, no-upfront cost and simple license structure just like Office 365. And right now, Access users must accept:
· No global assembly cache
· No server to connect to
· No installed services like .NET – doesn’t exist, not there
So older apps, unmanaged code, Office 2003 and earlier, Access, these depended on registry to store all their environment stuff in. VMware didn’t exist, no hyper virtualization, so when installing the software, it expects there to be a Win registry somewhere, to install its srvc in root for (admin rights to use), so no srvr to install the drivers on, Virtual mach has a “guest OS” a copy of a ghost machine that WOULD HAVE existed, NOW have wrappers like kubetes/dockers (expensive). Note MS can run an IBM 3770 using emulator.
Email 12/13/2018 TITLE: AccessDB is the BEST - AccessDB is the WORST
Microsoft Access is probably one of the most successful solutions Microsoft ever made. Access is a great product that has outlived and out grown its intended reach. Access has millions of users currently so it naturally has a huge number of “Backers” who have vested interest in seeing it continue. The cost to replace Access is significant in terms of project cost and business disruptions. The cost of staying on it could be even higher. This cost is easily divided into two simple categories: 1. Cost to wrap Access in a security/compliance blanket forcing it into compliance with current policy. 2. Cost (risk) to insure the business against its failure. For companies insurability is a huge factor. For government it is the legal risk cost.
Access by its very design is one of the best hack apps ever built. It is CIO’s worst nightmare. It invades every layer of the operating system stack from hardware drivers, global assembly cache, network, security, registry access, WMI, and it will load and execute ANY executable code on your computer or on your network.
For the above reason, most system administrators restrict users to lower access rights on the network (a security/compliance best practice). Access needs elevated rights to run many of its services. In the Window 10 world it is prevented for executing external code. This renders lots of Access apps useless.
Email 12/13/2018 TITLE: Old apps don’t play friendly
Windows 7 came out in 2009. Multiple monitors were beginning to become prevalent. DPI, dots per inch, has to do with visual presentation on screen and printers. In short old applications either had no awareness of DPI and multi-monitor or defaulted to off. This caused interesting issues.
This is a problem in modern installations where there are multiple monitor used and the monitors support different resolutions and are different sizes physically. The issue is that some applications are unable to size to the screen making some content not visible or controls off the usable screen. This depends a lot on how the screen was designed by the app developer.