I can't see what kinds of utilities would need to run in another
instance of Access in order to operate on other dbs.
Here are a couple cases where I use automation.
I like to automate my build process in preparing a new install, to make it
faster, more robust, and more error-free. To my knowledge, the only way to
compile a front-end to a compiled .mde is using automation, using something
like: appAccess.SysCmd 603, strMdbFile, strMdeFile.
I like to perform automated testing of my front end during the build
process. For example, I open queries using a testing harness, display all
forms (partly to check for column widths and overlaps), and display all
reports. (Such testing can verify that there are no field renaming or table
renaming problems, for example.) Anything that requires DoCmd in the front
end requires automation, if you are running it from a testing or build
harness as a separate programmer tool. This is even more useful if you have
multiple front ends in your application, which might be installed for
different users but within the same build and/or install package.
- Steve