JDubya, you were confused because you asked the question about Access, but the problem is actually a Windows question.
If you launch 3 applications using a window and a mouse click or any analogous method, each click launches MSACCESSS.EXE, and you can confirm this with Task Manager. Each of these starts a Windows Process which has its own separate resources - including its own allocation of physical memory. Since it is the Access front-end that contains the DBEngine, your 3 processes all have independent workspaces that, due to Windows security, cannot "see" each other. This is because WINDOWS is keeping them from being able to overlap.
Most people don't think about it because they don't that often get involved with Windows Server 2xxx. However, back in the days when Windows 98 and Win2k and WinME were current, Microsoft wanted to sell a LOT of workstations to the U.S. Government. However, there was this thing called the "Orange Book" - part of a series of government standards collectively called the "Rainbow Series" - that described certain properties that were the basis for evaluation of an operating system's readiness for use in government offices. The target standard was something called "C2" and all of the (then) DOS-based PCs would have failed the evaluation. The problem was that even though they ran Windows, underneath they still ran MS-DOS and THAT would have kept them down in the D evaluation levels.
At that time, Microsoft commissioned Dave Cutler et al. to rewrite the Windows Kernel code so that it could at least be C2 compliant, as that was what was needed to be allowed to run "Sensitive but Unclassified" (SBU) software. I was with the U.S. Navy at the time as a contractor and saw all of Microsoft's gyrations from the outside, but I kept up with publications and knew what was happening.
Windows NT came out and it met C2 requirements. Subsequent versions of Windows (technically starting with v4) have a Windows Kernel, not a DOS Kernel, and are able to perform the isolation required to meet that standard. In fact, as time has marched on, Windows has reached the level that allows it to run stuff at Secret level. The "Orange Book" has been replaced, but by that older standard it would mean that Windows is up to at least the B1 level. ("A" level is Top Secret and I have not been on such systems so can't tell you much about that.)
Why is this relevant to your question? The answer is that in the more secure versions of the Windows environment, whether Server or Desktop, processes that run simultaneously by taking chunks from the same pool of physical memory are NOT ALLOWED to see into each other's spaces. Isolation of parallel processes is part of the requirement that Microsoft was addressing when they build Win NT so many years ago. It is how you keep hackers and malware at bay - by using advanced memory management to assure that "the left hand doesn't know what the right hand is doing."
Therefore, when you look at "DBEngine(0).xxx" properties, each separately launched process has only one DBEngine. At least in theory, but I've never seen it done in the real world, it would be POSSIBLE with Windows for a process to launch multiple threads in the same process space and trigger a second copy of the database engine in a separate thread. However, Access wasn't written that way. The reason you are seeing "DBEngine(0)" and not just "DBEngine" is because the Component Object Model is rearing its ugly head. That is just the formal way that COM requires you to access things in its heirarchical series of object pointers.
Now, the theoretical question about DBEngine(0).Workspace(number).Databases(number) - works like it does because you have access to the DBEngine primitives to open workspaces, and you have access to the Workspace primitives to open databases. But you don't have access to the thing that is above DBEngine(), so you have no primitives to say "Add another engine." That would done at the process level and the COM API doesn't take you there.
So this is why you see what you see. Hope it clarifies for you what you see and why you see it that way vs. any other way.
