I'm not going to bother you with the thread count. Only this much: The single Access (365, V2301) process used 7(!) different CPU cores (of 12 available) while executing that query.
Remember that Windows uses an internal "round-robin" scheduler to speed up context switching and as a way to diminish heat load on any one CPU core. Was that usage seven cores simultaneously or in sequence? I.e. did it just happen to touch seven of the twelve cores before the query was finished? That COULD have been because the query only took seven internal scheduler cycles. Not sure about how long that would be, but if it is even something like 16.66 msec, that is literally 50 million instructions per cycle. AND if it is working fromn a SSD then the disk latency isn't that long either. The query you named only returned 3800 records, which isn't very many.
I used to run an OpenVMS with an 8-thread Longhorn CPU (64-bit) from Intel. I know for an absolute fact that my single-threaded processes nonetheless used multiple cores. And the same guy who wrote the kernel of OpenVMS (Dave Cutler) is ALSO the guy who wrote the security and scheduler kernel of Windows NT - and he explicitly reported that he used VMS software designs for a lot of things. He got away with that because for a while back then, Microsoft and Digital Equipment Corp. had a teaming agreement in which they shared technology. That is also why OpenVMS can run on IBM XEON processors. And that is why the Windows Memory Dynamics almost perfectly match OpenVMS methods.
The problem here is that the Access MAIN code was designed to be single-threaded and to run in a single-threaded environment. As I said, if you use some kind of API, you can multi-thread within VBA. We had someone about three or four years ago who wanted to multi-thread while using WinSock routines as a listener while running other queries and VBA. So I will not say it is at all impossible. I said, and I meant, "fresh out-of-the-box" Access is fully synchronous due to single-threading.
In your video you split hairs regarding VBA being interpreted, emulated, or executed. The correct answer is "emulated" for VBA, "interpreted" for SQL (I think), "executed" for the code in the libraries and MAIN program. I don't dispute the possibility of methods to trigger multi-threading. I don't dispute that you could build your own DLL to go multi-threaded. But that deviates from the question at hand.
In the original post that triggered this diversion, the question came up as to having things happen between parent and child forms. The OP was asking for something that isn't built into Access. Using the API calls to create threads, perhaps he COULD have gotten some level of simultaneity, though I doubt it because of there being TWO forms and because we cannot see the Access portion of form code, only the event code that we write. We can get an event routine to create a program fork, but whether Access would honor it is a totally different question. I'm not sure what would happen if a child form with fork-level code suddenly gets closed with the forked code is still active. I also question what would happen when the forked event code does an Exit Sub while some other form code does a simultaneous Exit Sub. Which thread becomes primary? You pointed out the need to protect threads from each other. I believe that in an emulated environment, that might be more difficult than for a truly compiled environment. (The latter is only a statement of opinion.)
But for either case, the line from the old TV show "The Honeymooners" comes to mind... "Bang, Zoom, straight to the moon." One slip-up in the context of the parallel execution setup and things WILL crash. Your disclaimer at the front of your video IS absolutely correct - this technique is not for production use.
)
