Run Macro in Another Database

[tcarriero]

Is it possible to run a macro located in another database? I thought that perhaps I was on to something when I found TransferDatabase in the macro options but that would only allow me to import, export or link. There may be some kind of code that I could use on the on click button option on the form but I'm no expert here. lol

Any suggestions you can offer will be appreciated.

[HansV]

You have to open the other database in another instance of Access in order to run a macro in it. But keep in mind that the macro will run in the other database, not in the currently active database. Is that what you want?

[tcarriero]

Hans,
I've made a mess.

There are three different groups that use dealer information. Over time, I've built 3 small databases for them to work with. It's to the point where they really should be combined so the data can be shared between the groups. I really have to keep a handle on the size of the database because the information is not only shared on our network, some users will be remote.

At the time that they were built, they were put together kind of adhock but as they saw the value of Access, the databases grew. My first attempt was to simply bring all of the information into one database. This was a disaster because some of the buttons and so forth carried the same names and it was quite large.

Because I will be starting from scratch, I decided to try my hand at the frontend / backend application. I'm at the ground floor. I realize I haven't given you a lot of information but with your experience do you think that will be a good approach. I would hate to continue on the frontend/backend path if there's a better way to go about this.

Combined Database Issues: multiple user - network - remote users, connecting with highspeedD

[HansV]

A backend-frontend design is the way to go, it means that all users will be working with the same data. But if you have 3 different groups, there is no objection to using 3 different frontends, all linking to the same backend. That way, you can provide different functionality to each of the groups, without sacrificing the advantages of a shared backend.

[tcarriero]

Oooh. Good thought. I was having a bit of an anxiety attack thinking about how I was going to keep so much information straight, once it was combined.

[Wendell]

That approach also has it's drawbacks - if you create three different front-ends, there will undoubtedly be situations where you need to change things in all three databases. I have that situation with 7 different clients who have a backend that is identical - though the data is different. But the front-ends are all unique in at least some respects. So if I find a bug and have to change it I end up going to 7 different (and complex) front-ens to make the change. So weigh your approach carefully, and see if perhaps using user login information (Windows User ID or Access User Security) you can present different interfaces to each group. See Why Split a Database for some thoughts on the front-end / back-end approach.

[tcarriero]

Thank you Wendell. I'll read into the attachment.