I found that internal databases were common to all open add-ins.
The problem is that the table links to the second calling application overwrite the table links of the first application.
I'm coming to this late. I will have to be careful with nomenclature here because casual references might be confusing.
When you log in, you create several things including a SESSION (which is a resource accounting entity) and a task (or more precisely, a
process within a task). You absolutely CAN open multiple tasks in a session. I.e. spawning tasks on your desktop such as opening Word and Excel side-by-side (neither one maximized) with the Desktop still open behind both programs.
If you did that and poked around with Windows Task Manager, you would see several processes, each with a unique process ID. If you have a program that is capable of multi-threading, each thread - when active - runs in the context of a unique process. The process terminates when the thread terminates. Each process has its own memory and other resources. For most Windows desktop situations, you don't have user quotas, though if you were on a Windows Server implementation, you might run into per-session quotas and limits.
Here is the side-effect of what you are doing. If all of the add-ins are open in the same process (defined by having the same process ID), they are sharing the same virtual memory, too, because of Windows task isolation rules. Multi-threaded programs can share the same code and data space because a process can set up the shared-memory conditions as part of the multi-thread setup. The task can spawn a child process that can share the code with other child processes. But in the absence of a multi-thread environment inside your task, you will have a single process with a single set of resources allocated to it. This will be particularly true with Access, which was NOT written to be multi-threaded.
This means that when you open your Access database that activates this add-in, if the add-in ALSO opens an Access database, you are still in the same process and MUST - by Windows rules - share the same virtual memory space. (And same memory copy of MSACCESS.EXE.) They are part of the same process and therefore CANNOT isolate themselves from other databases that are open in the same process. The distinction is that "same SESSION" processes can operate independently for the duration of the relevant processes. They have independent memory and CPU resource allocation. But what you have described is NOT independent. It is all part of one big conglomeration.
At least part of your problem is therefore that you cannot isolate the multiple internal databases because they share the same virtual memory space. You can open a second calling application only by having ANOTHER set of qualifier variables to track the new DB different from the ones you used for the previous DB. In a sense, this is a vicious recursion problem where part of the recursion is triggered from the Add-In.
