Who Lit the Fuse on Access?
Updated: Dec 22, 2018
Whoever . . . the fuse has been burning for over ten years - any important data in Access needs to know
Ten Gotchas - AccessDB will not run in Windows 10
On a need-to-know basis, we all need to know this. First, 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, any one of which will stop Access dead on Windows 10.
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
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).
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.)
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.
Cloud servers do not have a Global Assembly Cache because it is not compatible with cloud virtual scale.
Access in cloud virtual environment is not supported on Window 10 virtual machines for the above reasons.
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.
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.
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.
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!
Using an XP virtual will run AccessDB . . . 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.
Another big " . . . but list" (dealing with Access 2016)
So, the other day an old Cogger put me to the test, “I have Microsoft Access 2016 64-bit, and it opens and runs on 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 is limited to these conditions: and here's an interesting item that likely happens more than we can even imagine. It makes me wonder how many man-hours might be saved by greater awareness of technology: https://www.theatlantic.com/technology/archive/2018/10/agents-of-automation/568795/
Within eight months of arriving on the quality-assurance job, a coder had fully automated his entire workload. “I am not joking. In the past six years, I have maybe done 50 hours of real work.”
Where are We Headed?
Here are a few predictive observations:
1. EDGE will be our desktop - a virtual desktop.
2. Microsoft will keep doing amazing things. And I've heard that EDGE won't even work with Windows16.
3. There will soon be a single sign on - for everything we do - everywhere (good for security if it works right).
4. Very soon (now?) coders will be separated into three classes: (1) DIY/the app user, (2) average code jockey, often/mostly GitHub cut+paste code snippets, (3) Code specialists/ engineers.
5. Everything-as-a-service. Everything Cloud. The best model is Platform-as-a-service. Recently we're hearing Data Center-as-a-service (to help .gov get their Cloud direction started.
Final Words (for this post)
If dealing with a business problem, to see how to get technical about it, don't hesitate to look at both new and prior technology. Join PTG as a Member - we'll be looking in all directions, too. My favorite example is, in building the space shuttle, the engineers were stumped on how to control the heat on reentry, so astronauts could survive. The answer? Specifically design it to burn up (ablation / ceramic tiles), look at old practices of glassblowers, tile makers.