>> currentDb access.application

[David W. Fenton]

Perhaps you forgot the earlier parts of this thread, to which you
replied already. Other launch examples that I proposed:

All your examples were development rather than production uses, and
I am thinking about production code in an application in the field
that would benefit from opening another instance of Access (and,
yes, you're right that I didn't say that!).

[]

Another case for launching is when you have multiple related
applications with different front-ends and back-ends. In my case,
I do this in a few cases for the user to perform complex data
imports from external sources, which is implemented as a
separately launched application (also separately maintained and
funded). I do not use SOON, I simply launch a new instance and
close the prior instance.

I have not encountered any circumstance in my professional
development where there was a need for such related applications. I
believe that from the standpoint of code maintenance, it's much
easier to maintain a single application and then tailor the UI for
the particular specific use. The key clue to me that multiple apps
are a problem is when you have the same UI object
(form/query/report) in more than one front end.

One way to also approach that would be to use a library database (or
to treat the other apps as library DBs) with the common objects. But
again, I just don't see any reason to maintain separate apps.

But launching an app from another app is just the same functionality
as SOON, so I would certainly count it as a valid reason for another
instance of Access to be opened. What I *don't* acknowledge in a
production application (i.e., not during development) is any but the
one case of launching another instance of Access, staying in the
initial instance, and then shutting down the additional instance.

I just can't see any non-development reasons for that (other than
the one I've already adduced).