@ Welshgasman #15. Well, I did work in that environment. It was handled differently and mentioned in post# 8.
Also, I spent a lot of time with instances, and reported in at least one thread here all the problems that were going on and how Access got very confused as to which instance code was running for.
allenbrowne didn't get very deep into the "feature" and no one on this forum had an answer to what was going on:
https://www.accessforums.net/showthr...light=instance
On the last round of minis that I worked on, one would just login again to another instance of the "data account" (where all the client data was). There was no need to shutdown the open session, and the O/S never corrupted data between login sessions unless something very bad happened outside normal operations. There was no need to make duplicate copies of the application software just to start another instance. We had dozens of workers all working in the same "form" (called data entry screen) at the same time for the same data account without problems for decades. Before that, in college, we had hundreds of students all running the same program at the same time on the mainframe. It's not a new concept, except to MS. Had the MS Access team looked around when they started with the toy db for one-up users, they would have realized the need to shadow copy the .accdx file, or some other sandbox method, so that multiple instances didn't become a source for corruption.
Building an instance for one form, even if it worked okay, would then logically require the menu application to be able to instance any form (or report) that the user might want to use in duplicate+. Oh boy, let's not go there seeing that it can't work properly with just one form opening multiple times.