I converted my database to a Design Master on a local server in PA, and created 2 replicas which reside on servers in MA and Mexico. It seems to be running well and my plan is to do the following on a weekly basis:

1. Pull data from various production systems into the Design Master
2. Compact and Repair the Design Master
3. Synchronize the 2 replicas with the Design Master

I have automated item 1 and in researching how to automate items 2 and 3, I read posts that say you should not compact and repair a database unless it is resident on the same machine that runs the compacting program. I'm not clear on what that means. My database resides on a local corporate server but MSACCESS.EXE (assuming the compaction program resides within) resides on my laptop's hard drive. Is it suggested that I move my Design Master to my laptop's hard drive in order to compact? I read that moving or renaming any of the contents of a replica set is a NO-NO.

Additionally, most of the posts I've read on compacting refer to databases that have been split. I elected not to do that some time ago for simplicity. Should I reconsider?

Thanks for any help,

Basically you what to have the MDB/MBE on a local hard drive for the PC that is running the compact function.
You do NOT want to be sending the data across a network.

IMHO, it is always more simplistic to work with a "split" app.
You should never develop on the "master" copy of an MDB.
You should always work on a copy.
If the app is split, you just replace the "master" with the tested copy.
If it is not split, you have to import all the changed objects. (That does not sounds like more work to me.)

Boyd, thanks for the help on compacting. Regarding replicating, however, at the link

http://msdn.microsoft.com/archive/default....ourdatabase.asp

there is much info on why and how to use the Replica method which seems to conflict with your advice, but there is no mention of splitting:

"If you want to make changes to the tables, queries, forms, reports, macros, or modules, you make those changes in the Design Master..."

"With database replication, it is no longer necessary to make backup copies of your database..."

"Although it's possible to back up replicas by using traditional backup methods, it's strongly advised not to back up and restore replicas as you would ordingary files..."

When the Design Master is periodically synchronized with it's replicas (using the Synchronize Method) it can be automated and pain-free. Using this method there are essentially three identical copies of my database with a few extra tables added to keep track of members of the replica set. One of these copies, the Design Master, is the only one that allows design changes. Additionally, the help says "If the Design Master is damaged or unusable, don't copy or restore an older version of the Design Master; instead make another replica the Design Master."

I guess my REAL point is that I don't see the advantage of splitting into FE/BE (at least in my application). I am replicating because of performance considerations (the PA database is understandably very slow when accessed from Mass or Mexico). If I split and put the back-end data on the PA server and front-ends on various machines across North America, performance is still a problem and management of it seems considerably more complicated than clicking a command button to synchronize all 3 replicas. These replicas are on the user's local servers and performance is fine.

Any clarity on this issue would be welcome. Thanks,