First off, forms/reports/macros/modules should not be replicated.
Only data tables and queries should ever be replicated. The reason
for this is because replication is a *Jet* technology, not *Access*,
and only tables and queries are pure Jet objects.

What this means is that you're taking risks with replicating Access
objects, because they have custom properties (from Jet's point of
view) that Jet won't necessarily know how to take care of.

Furthermore, front end updates are only ever one-way, never two-way,
but replication is entirely designed for two-way synchronization.

This means that changes to data in the objects end up getting
propagated over replication. A perfect example is a filter setting.
A user in one front end may filter a form. This gets automatically
saved when the form is saved, and that will be synchronized with the
other replicas. If every user is filtering their forms, that means
many conflicts.

But it's all a complete waste of time, because it's not data that
ought to be synchronized in the first place.

Now, keep in mind that from A2K on, your Access project (forms,
reports, etc.) is no longer stored in a series of records in a Jet
data table, but within a SINGLE RECORD in a Jet table (this is why
saving a change to a single form in A2K is slower than in A97,
because THE ENTIRE ACCESS PROJECT HAS TO BE SAVED, instead of just
the single form). What that means is that every change to a property
of a form/report, etc., means a change to the generation of the
record that holds the Access project, and that means conflicts,
conflicts, conflicts with all the other replicas.

WHat happens is that eventually (and sometimes very quickly) these
problems mount up and the whole project gets irretrievably
corrupted.

Now, it could be that you are *not* replicating the front end, and
simply encountered your garden-variety VBA corruption. This can
happen if:

1. you never compact your application while it is in development.

2. Access crashes while you're changing VBA code.

3. you do not turn off compile on demand.

4. you never clean up the crud by decompiling.

For information on this, see:

 The real deal on the /Decompile switch:
 http://www.trigeminal.com/usenet/usenet004.asp

I make decompiling a regular part of my development process. In A97,
I do it at least once a day when programming heavily. That consists
of this set of steps:

1. back up the MDB to be decompiled.

2. decompile it.

3. close the instance of Access used to decompile.

4. open a new instance of Access and compact the decompiled MDB.

5. in the same instance of Access open a module or the Debug window
and choose COMPILE AND SAVE ALL (A97) or COMPILE [project name]

6. run a compact again.

There are two main benefits to this process:

1. it keeps the MDB small and efficient

2. it works as the canary in the coal mine to inform you of
corruption of the VBA project early on.

Because of the 11 levels of compilation (see the Trigeminal.com
article), projects can become corrupt and still successfully
compile. When you decompile, the compiled code is tripped out and
all that's left is your VBA code. When you compile again, Access
will occasionally find compile errors that did *not* show up
earlier, because the problematic code was marked as already compiled
and not rechecked for correctness.

Last of all, in TOOLS | OPTIONS, be sure to turn off compile on
demand. In A97, this is on the MODULES tab, and you just uncheck
COMPILE ON DEMAND. In A2K and later, you go to the VBA code window
and choose TOOLS | OPTIONS and on the GENERAL tab, uncheck COMPILE
ON DEMAND. In both versions of Access, I add a COMPILE icon to the
toolbar and compile after every code changes (In A2K, I also save a
lot, since it's very easy to lose changes because of the
independence of the code window).

None of these issues are replication issues, though!