MICROSOFT VB6/ACCESS – REVISITED
Originally posted on August 15, 2018 by Larry Aultman, on laultman.wordpress.com
ARE YOU DEVELOPING WITH MICROSOFT ACCESS OR VB6? IF SO STOP!
In this article I revisit some of my past articles about VB6/Access and why it should not be used to develop new solutions or to even modernize using the Access application.
Note: If your business runs only Windows desktop computers and you have absolutely no plan to move any of your business to cloud and security is not a concern, this article does not apply to you.
I have written in the past about Access and have re-read my articles from 2016 and 2017 to make sure I am giving solid guidance to readers. In my opinion, the move away from a desktop database like Access and its cousins Paradox, FoxPro and others is a sound one. I include VB6 because it shares many underlying inter-dependent Windows specific features used in Office applications (including Access).
My company has solutions for these problems. Letting Intact take over the issues might be the right answer for you. Government Customers: Access database is a large risk to your security concerns, and a large risk to your application support concerns. I don’t want this to be a long in-depth treatise on Access, rather a list of helpers that you can go read for your situation.
VB6 and Office applications using VBA, including Access Simplifying: I use the word “supported” below very often. It means that applications built with a “supported” technology (a collection of files) has all the dependent files always available on any of the “supported” Windows versions. Special note: Windows 10 as of April 2018 (build 1803 or later) is now subscription based and is not listed in the Microsoft support list for these applications.
UPDATE: Some seemed confused about the link to VB6 support below when we are discussing Microsoft Access. For clarity, all Microsoft Office desktop applications included Visual Basic for Applications (VBA) and many still do. This dependency is a Windows operating system (OS) wide issue that affects ALL Windows operating systems. To explain just a little about it, all VBA and applications developed using Visual Basic Integrated Development Environment (VB IDE) share a single (across the whole computer) “VB runtime” process. Over its 25-year life-span VB had six major version releases, hence VB6. Access developers used VBA extensively in their applications. Moreover, because the VB runtime dates to a time before multi-threaded OS and processor chips it is by nature a “single thread” process. This means that every program using any VB or VBA code must share the same thread. This worked very well on old 1990 desktops running Windows 3.x with Microsoft DOS underneath. Things changed in the late 1990’s and so too did the development. The VB6 IDE was officially dead in 2008, but VBA lives on in desktop versions of Office albeit stripped down and turned off by default today. Will Access run on your new 64 bit device with Windows 10? Could, might not. No promises from Microsoft.
If you have applications based on these technologies which includes Access prior to 2013 see this 1/2018 Microsoft support document. Of special note, the VB6 IDE tested systems do not included Windows 10, only the support policy for Windows 10 is updated. You must read carefully and understand affected systems. If you have VB6 or Office applications that you either purchased or built to use the VB-runtime on Windows, it will continue to run on supported Windows operating systems within limitations. This means that files shipped with the software AND were on the supported list are still supported, however your application may use files from the \tools extensions or from third-parties that are no longer supported. Microsoft does not guarantee that these applications will continue to operate. Will my app run on Windows 10? If you use a 32 bit machine or you are able to run in a WOW mode on a 64 bit device and your application does not have any third-party controls or does not use any of the now unsupported controls, it should.
What about security, user rights, and roles? There isn’t any other than the Windows log-on. If it is on the desktop, it is pretty much open season. A really sharp IT pro can lock down a system, but that is expensive and makes the system fragile.
I connect to a SQL backend, what is my problem? There are two immediately. One, the embedded connection string or a DSN file connection to SQL is not secure and is a known risk. Two, using cloud API’s requires completely new code that does not exist in these older system runtimes.
I have Access 2016 on Windows 10, will it work? If you have a simple desktop application with the Access database file at least upgraded to version 2007 and you are running on a 32 bit edition of Windows 10, then it will most likely work, although some features have been removed since 2007 that could cause you to get errors. Links to support: see the links above in this article to additional materials.