Developing for users with multiple Access versions

Question

I am now working in an environment of multiple Access client versions.  Previously, I've been fortunate to have all users on a single version, so this is new for me.  The rule of thumb is to develop on the oldest version in use, but I'm looking for slightly deeper information.  Users here are using 2013, 2016 and 2019 MSI versions.  Some full Access, some runtime.

I am not sure what is happening, but with an application with a shared back end, I've seen instances where if users using different versions are accessing that back end, some users will get unrecognized database errors from the back end.  If only users of one version are accessing, this appears not to happen.  There are nothing but tables in the back end.  No table macros or any other code.  No features newer than 2013 are employed.  I am wondering if the first in or first out of the back end is somehow changing the back end's active version properties in some way.  I'm not sure how to begin troubleshooting this.

I've come across vba late binding as a topic, but am unclear whether this refers only to manipulating foreign applications, like Excel or Outlook from the native application of Access.  Can vba late binding apply within Access when dealing with multiple Access versions and perhaps alleviate some of these Access Version issues, or no?  If so, how?

Looking for best practices for this multiple client version scenario that are more detailed than simply using the oldest version for development.  Thanks.

Answer 1

In addition to what Daniel said: make sure your app can handle 32- and 64-bit, so your declarations need to be PtrSafe. Then you need to have both bitnesses on your development machines (plural; cannot have both on 1 machine, but can have on main machine

• VM on that machine) so you can test and importantly build the accde for each bitness. Then you need a mechanism to deploy new versions.

Answer 2

Regarding late binding, it is normally used when automating other applications.  Within Access itself, although you could, there really isn't any benefit.

With regard to the unrecognized database, I'd be leaning towards https://www.devhut.net/2018/06/13/access-bug-database-is-in-an-unrecognized-format/

My experience is to keep things simple and this guarantees the greatest compatibility.  It's when you get into special features that you commonly get into problems (new charts for instance).  You need to stay on top of deprecated features as well.