Unfortunately, yes.
I'll try to explain. Windows was developed at a time when people talked about "memory models" - having to do with how the hardware memory management system worked. Different versions of memory management hardware provided different amounts of address space. These models started with the "16 bits is all you've got" model based on 16-bit addressing of the Intel 8008 chip. Those machines could NEVER exceed 64K of RAM. But over time, models progressed.
Office 32-bit versions grew up with the "large memory model" that says that you have two major divisions of any Office task memory. Using the then-current 32-bit model, they took the 32-bit address pointers and sub-divided them. The two divisions were then two semi-independent "address spaces" in which Access, all of its libraries, and anything else you had, all would get placed into one or the other of the two spaces.
In this model, "low" memory (0h00000000 - 0h7FFFFFF) was for MSACCESS.EXE itself plus any library references, the program stack & program heap (two large working areas) and a few other elements. Library references could go anywhere within the low space because they are called "dynamic link libraries" in which all addressing is relative to where it is located. That is, if you know about the hardware registers of your machine, the Program Counter (which is a register that keeps track of the next instruction to be executed) can be used as an offset for addresses so that you could drop it anywhere in memory and just have a pointer to that location to find the entry points in that library. The Stack Pointer register was also used for calls that established a stack "frame" - basically, the data structure that temporarily holds all of the local variables of any sub/function.
The low memory would be where you had all of your library routines that arrived through something OTHER than your VBA code modules. One of the overhead items in that structure is in the bottom of low memory because in that model, the memory management data (identifying the various distinct memory segments in the various distinct program elements) occupied the low 1 MB. Address 0 was NEVER memory mapped (which is how Windows tasks catch undefined addresses - with a memory management exception). Since it is ALL virtually addressed, there can be gaps between modules but the gaps don't waste physical space.
The "high" memory is actually easier. Whatever is in the .ACCDB (or, originally, .MDB) files goes to high memory. Got multiple files with multiple tables? Doesn't matter. The memory management can be dynamically "diddled" so that if you have to address something in file A, the correct pointers can be loaded for it even if the internal addresses would conflict with file B. However, because of these individual files all being developed originally as single files at the time of their development, they are ALL based on the starting address of 0h80000000. So to address the contents of one App file or one BE file, you must load the appropriate memory management pointers when you load the actual address. Now, if you think about it, this is why you cannot have a relationship between tables in different files - only one of the tables can be mapped at a time and for a relationship you need to map TWO tables.
Anyway, because these were 32-bit addresses, their total address space was 2^32 bytes or 4Gb. The subdivision into high and low memory meant that the core code and libraries and memory mapping overhead plus the stack and heap had no more than 2 GB, and whatever you had from DB files had the other 2 GB.
Now come forward in time to the introduction of 64-bit Office. For reasons known only to the MS board of directors, the internal structure of Access was NOT fully upgraded in the same way that Word and Excel were, because Access still is limited to that "large memory model" architecture. It did not get expanded to the "very large" model. It still contains the high/low division to 2 GB each. Even though there have been a FEW improvements including the ability to call routines that use 64-bit addressing (see also PtrSafe discussions), the core of an Access DB file is still firmly rooted in 32-bit memory models and thus is still constrained regarding total size.
Since that "high" segment also encompasses ALL of the .MDB / .ACCDB files and does not overlap into "low" memory, that means you still have no more than 31 bits (2 GB) of address space for a single DB file... but you ALSO have only 2 GB worth of address space for the running application no matter which files it happens to be mapping at the moment. Yes, it CAN address a lot more than 2 GB - but it only can do 2 GB at a time, and no table can cross one of those implied segment boundaries.
@amorosik - I was not attempting to demean you with the joke about the horse, I was attempting to inject levity into what had become a highly contentious thread. But if you note the responses you were starting to get, you will realize that our frustration begins to emerge as we continue to offer our best answers and you continue to reject them.
If your question continues to evoke this kind of response, then from what I am seeing, our responding members can only see two possibilities. First is that you have some agenda to intentionally provoke us. Second is that you have not been able to correctly frame your real question and thus have left us frustrated in trying to understand what you are really asking. That is, we have a "logical communications disconnect" somewhere.
