Thomas great question, and you're absolutely right to be skeptical of Microsoft's terminology. In this case, however, "instance" really does mean a separate running copy of Microsoft Access.

When you open multiple ACCDB files by double-clicking them, Windows typically sends them all to the first copy of MSACCESS.EXE that's already running. In Task Manager, you'll see one MSACCESS.EXE process with multiple database windows underneath it. Those databases all share the same executable process, which means they share the same address space, loaded VBA engine, add-ins, and other internal resources. If one database hangs in startup code, gets stuck in an infinite loop, or encounters some other issue, that entire process can become unresponsive, and every database running inside it is affected.

When you launch a database using a shortcut that explicitly calls MSACCESS.EXE followed by the database filename, Windows starts a brand-new MSACCESS.EXE process. That process has its own private memory space, its own VBA engine, and its own set of resources, completely isolated from the other Access processes. If one of those processes crashes, the others keep running just fine. That's what I mean by a separate Access instance. It's not just a logical distinction. It is literally a different Windows process, exactly as shown in Task Manager.

So your analogy to object instances is actually pretty close. Each process is its own copy of the Access application with its own state. They may all be running the same EXE file on disk, but once loaded into memory they are independent. Think of it like opening several copies of Notepad. They all come from the same notepad.exe file, but each one is a separate running program. Same executable, different processes, different memory, different fate if one crashes.

I did a little more digging on this and wanted to give you the full technical picture of what's actually happening under the hood.

When you double-click an ACCDB file in Windows Explorer, Windows doesn't just blindly launch MSACCESS.EXE. It first checks something called the Running Object Table (ROT), which is a system-wide registry that Windows maintains of all currently running COM servers and objects. Microsoft Access registers itself there when it starts up. So when you double-click a second database, Windows sees Access is already in the ROT and instead of spawning a new process, it hands the open request off to the existing one via DDE (Dynamic Data Exchange). That's the exact mechanism that routes your second database into the first Access process rather than creating a new one.

That's why all those databases end up sharing the same address space, the same VBA engine, and the same loaded add-ins. They're literally running inside the same process. One crashes, they all go down.

When you launch Access using a shortcut that explicitly calls MSACCESS.EXE followed by the database path, Windows skips that ROT lookup entirely and just spawns a fresh process. That new process registers itself separately in the ROT and gets its own memory space, its own VBA engine, completely isolated. That's a true separate Access instance in every sense of the word.

So your instinct to be skeptical of Microsoft's terminology was fair, but in this case "instance" really does mean what it should mean: a separate, independent Windows process.

And that's also why you can kill one in the Windows Task Manager, and all of your access databases don't shut down then.

Interestingly, the same principle applies to all Microsoft Office applications. They all use the same ROT/DDE mechanism under the hood. Word behaves exactly like Access. Double-clicking a DOCX file routes to the already-running WINWORD.EXE process. All your open documents share the same process, same memory space, same VBA engine. If one document runs a macro that goes haywire and hangs Word, all your open documents are frozen with it. Launching via an explicit shortcut to WINWORD.EXE with a filename creates a true separate process.

Excel is mostly the same, but with an interesting twist. Prior to Excel 2013, it was notorious for this single-instance behavior, and it caused real headaches because separate workbooks couldn't have independent calculation engines. Starting with Excel 2013, Microsoft introduced SDI (Single Document Interface), where each workbook gets its own window and its own taskbar button, which looks like separate instances. But that's largely cosmetic. Under the hood they still share a process unless you explicitly launch a new EXCEL.EXE. The explicit launch trick works the same way as Access and Word.

The short version is that this is really an Office-wide architectural decision, not something specific to Access. Microsoft built all of the Office apps to register with the ROT on startup and accept incoming document requests through DDE rather than spawning new processes. The workaround is the same across all of them: build a shortcut that explicitly points to the EXE file followed by the document path, and you get a true separate process every time.

Another useful side effect of opening Access this way is that you can even open two separate copies of the same database. Since each one is running in its own MSACCESS.EXE process, Access treats them much more like two separate users opening the same database.

That can be handy. For example, I have a task management database where sometimes I want to view two different tasks side by side. Yes, you can code around that by opening multiple instances of the same form, and I've covered that in my Developer lessons, but it can get messy fast. Opening the same database in two separate Access processes can be a cleaner solution, especially for simple viewing or comparing records.

Just be careful. Once you do this, you really are acting like multiple users in the same database. Don't edit the same record in both windows at the same time, and definitely don't make design changes while you have multiple copies open. In fact, Access will probably warn you that you don't have exclusive rights to the database at that time, so it won't let you anyway.

For split databases, this is usually safer when each Access process is using its own local front-end copy connected to the same shared back-end. For a single unsplit ACCDB, use extra caution. Access may let you do it, but that doesn't mean you should go full Klingon with a bat'leth in the engine room.

All good comments, and points out the failure of Windows to properly spawn proceses the way that IBM OSs and UNIX did for decades before Bill and Company decided to create a GUI on top of an inadequate OS architecture which has continued.

"Another useful side effect of opening Access this way is that you can even open two separate copies of the same database."
I'm not sure how useful that would be seeing that Access supposedly writes temporary data into the .accdx file instead of properly storing it into a reserved space of memory dedicated to that temporary data (that shouldn't modify the working .accdx file).

I've accidently run up against WORD working in "collaborative" mode, where two users can type into the same document at the same time. Amazing! But unfortunately, after saving the document, I wasn't able to open it again because of a reported corruption. Which again makes me think Microsoft is pushing for fancy use of its Office applications without first properly implementing the supporting architecture. The same goes for the "instancing" feature for forms and reports in Access. We've discussed its failures in other posts.

For those that weren't lucky enough to work with real computers before the PC/DOS/Windows arrived, here's the simple, age-old rule that Microsoft decided to defy in their designs: NEVER mix software with data.

This is why viruses started in you boot sector and continue to this day in every one of Microsoft's products that need continual "security" patches.

Yeah, I hear you. That's why I said to use extra caution if you're going to open two copies of the same database. I only do it if I want to see two records side by side. Usually I make sure one is read-only and I do my editing in the other one, but that's extremely rare. It's still a nice feature to be able to have.

I know Richard gets caution, but how cautious can you be if your support modules which are called by the two (or more) open forms can corrupt non-sandboxed modular variables? Are you never setting modular variables even for read-only records in a form? That's fine if your forms never use any VBA I suppose.

But it ignores the possibility of Access.exe itself stomping on the temporary and hidden bits of data it could writing into the same areas of the .accdx file.

Maybe two of the reasons our Access sessions hang or corrupt once we go beyond simple single-user, single-instance development?