DB return codes?

[GraeagleBill]

If DB1 app Shells to a DB2 app, is there a way for DB2 app to pass back a return code to the DB1 app? Like when DB2 app issues a DoCmd.Quit.

[Micron]

Interesting question. Maybe this https://www.tek-tips.com/viewthread.cfm?qid=682230

I suppose the quit code of the called db could write to a file as an alternative. Then db1 would read the file value.

[GraeagleBill]

I had thought about a file or even a transient file name plus writing and reading off the clipboard. I don't like using the clipboard unless I remain totally within the app itself so unless someone comes up with a better idea I'll likely go with a transient file name that can quickly be examined with a DIR function in a folder exclusive to both apps.
Thanks,
Bill

[isladogs]

Hi Bill
This is at least the third time I've answered similar questions in recent months
Yes its possible - whether its desirable is another matter

See this link for some code that you should be able to adapt for your needs fairly easily
https://www.access-programmers.co.uk...78&postcount=5

[GraeagleBill]

Hi Colin,
Not sure what your word of caution means:

whether its desirable is another matter

At issue is not so much a question of how to launch a macro in another DB but rather how to get a return code back when the macro ends (Quits).

As to your "RunExternalDatabase" function, my understanding is that I can use Shell followed by a "DoCmd.DoEvents" that will pause the code until Shell finishes but I've not yet found the VBA API function that can be employed to receive a return code being passed back from the Shelled app.

Bill

[isladogs]

Hi Bill

The example code was supplied for two different forum members who each wanted to:
a) open an external database, run a macro and close the 2nd database
b) close the current database

As I said in the linked post, I never understood at the time why the OP didn't just link the external database tables & run the macro or code directly but they didn't want to do that
Hence my comment "whether its desirable is another matter"

As I'm not sure exactly what you want to do or why, I've no idea whether its a sensible idea or not
But the code I posted definitely works and I think, could be adapted for your purposes

HTH

[Micron]

Not clear to me if you want the result of a procedure to be passed back or a value that indicates the shell process has terminated. If the former, I can only see this as being a write to a file solution. If the latter, I found api functions are identified in the link I have you, so I'm confused (again).

[GraeagleBill]

just link the external database tables & run the macro or code

1) I did not know that one could link to a macro in another DB, say DB2.
2) DB2 has links to privileged tables in yet a different DB resident on an NAS.
3) If one can in fact link and run a macro in another DB, there's still the question of
obtaining a return code issued by the macro on DB2.

I fear that what's required here could become un-necessarily convoluted. The macro in DB2 normally executes apart from DB1 or it could otherwise link to a table in DB1 and store return code(s) there. On the latter point, can the DB2 macro make a friendly inquiry of a linked table that might not be available?

[GraeagleBill]

Ah! Not interested in the return code from Shell, only the a return code from the macro that ran from a separate DB. See my post to Colin regarding a friendly inquiry of availability of a linked table. Baring that, I will write a transient txt file to a dedicated folder with the return code as its name and fetch the file name with a Dir function.
Bill

[Micron]

You probably would want to verify that a file with that same name doesn't exist and delete after reading unless you wish to accumulate them. You would think deleting would mean it's not possible for the file to exist on subsequent executions but the Kill process could fail.

[GraeagleBill]

delete after reading

Yes, exactly.
Thanks

[isladogs]

I'm still not clear after reading several posts what you want to happen.
Micron's last answer has unfortunately confused me further.

Let me ask the same question as I did to the two previous people who wanted DB1 to perform an action in DB2 which then needed to do something else in DB1.
Why not just run everything from DB1?

[GraeagleBill]

Sorry about the confusion Colin. The issue IS NOT how does one open an app in a different DB. The problem I was having had to do with obtaining return codes. I.e., how can the "launchee" communicate to the "launcher" how things turned out when the "launchee" quits?

[isladogs]

That's roughly what I thought you meant from the start but I'm still unclear why it can't all be done from the launcher app

[Micron]

Colin, I read the code and what I'm not seeing is how the result of a process (e.g. ABC123) gets passed back to the calling db. While I think that represents the goal, it sure would help to have an example of what the return value is and how it's derived.