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.