The way to execute code already in another DB (presuming it to be compiled) is to qualify the module, as CALL DB1.MySpecialSubroutine(...). However, if you wanted to insert code into another DB, there IS such a thing as creating a module and inserting lines of code into it. After all, an event wizard can insert code into a module. There's no "special trick" involved. You just pick a starting line where you want to start inserting and then it is merely a Module.InsertLine "text" operation. The trick is picking the starting line for insertion.
I've never tried to actually compile another DB, but you would have to compile it if you wanted to execute code you just inserted externally. I suppose if you could then launch that external DB and fire up some macro to get it to run some code, it would auto-compile - but you have to hope you have no compilation errors.
However, there is a logic issue here and I'm struggling to imagine who is doing what to whom? (Sounds like the punch line of an old limerick.) Gasman and theDBguy (both of whom are quite good) are scratching their heads over this and I can see why.
In the final analysis, if the code requires special attention in the context of the other DB, you probably CAN'T execute it from the original database "on behalf of" the other DB. You could execute it to take effect on your target DB from the original DB but it would still be in the context of that original DB's workspace. You could direct it to do its thing in that target DB by properly qualifying everything. At the end of all that, if you have to do a remote launch for context purposes, if it isn't properly self-contained and self-directing, it ain't gonna fly.
So, from my comments and the comments of my colleagues, I hope you can understand the focus of our confusion and perhaps clarify your intent.