Import multiple objects from another database at once

[jptros]

Is there a way to import multiple objects from another database at once? DoCmd.TransferDatabase works fine for only a few objects however it requires the database to be re-opened for each object which is terribly slow when importing several objects from another database. It would be nice if there was a way to record a macro going to through the import wizard which allows you to import everything only opening the database once.

[June7]

How often is this required to be accomplished and why?

[jptros]

How often is this required to be accomplished and why?

When there are lots of changes in the development front end it's easier to just reimport everything to the live front end so I've writen code and created a macro for pulling in everything except tables and linked tables from the development setup to the production setup. There are tons of forms, reports, queries and a good amount of modules in this application. Tracking changes and pulling them from a to b is a tedious process so I've automated it as much as I can to reduce human error (forgetting to pull over an object that has changed). It takes a good 5 to 10 minutes to reimport everything from scratch using DoCmd.TransferObject however I've noticed that if the Visual Basic editor is not open, the process goes quicker. When the editor is open, everytime a form is imported with DoCmd.TransferDatabase, the database is opened and the editor loads up a list of all of the form modules which has a pretty severe effect on performance.

[June7]

Import just because of design edits! What a pain. Not how I manage my split db. I don't really keep track of details of changes, I just edit and save and when ready, replace the production version. Review http://forums.aspfree.com/microsoft-...ue-323364.html

[jptros]

Ah yes, I think you misunderstood me. Updating the front end is done by me or one of the other developers working on features/bugs/enhancements/etc. It's then pushed out to users after the fact however there are still some good ideas in there such as the self updating database. Might have to look into adding that feature into our front end. Any how, we usually update the via logon scripts and if needed we will push updates individually to users. We keep 2 copies of the access front end. One copy is linked to development only data and has a config table which controls the paths to other databases it accesses dynamically. The other copy is linked to live databases and it's config table contains values reflecting the live setup. When we are done developing in the development database we pull our changes to the live front end and stick a copy of the updated front end on the network for users to get a copy of (or the logon scripts to get a copy of). What I've done is written code to transfer the forms, reports, queries, and modules from the development database to the live database to make updating a little less tedious when there are a large amount of changes. It's not worth the time of transferring everything for 1 or 2 small changes however sometimes we will do bulk changes or bug fixes and push them all out at once. Clearly this is the exception and not the rule, bulk changes are infrequent. Was just wondering if there was a better way to handle the automation of moving the objects en masse from the development front end to the live front end.

[June7]

Still not quite understanding the import approach. If the only difference between the two FEs is the pathing of table links and the config tables, then maybe just modify the table links of a copy of the development copy and replace the config table and publish that one out. Maybe my lack of understanding is because of the config tables. Never done that.

Back to your original question, no, I don't see a way to program the mass import.