I am having trouble with my replicated database. I am replicating
queries, forms and reports. In fact, when you set up a design
master Access automatically replicates forms, reports and macros.
If you had a properly split database, with tables in one MDB and
forms/reports/queries in another, you would replicate the data MDB
and *not* replicate the front end MDB.
I don't know why I keep
hearing not to do that.
Here's why it's dangerous to replicate a front end:
1. Replication is a *Jet* technology. What that means is that it
runs at a level *below* Access that knows nothing about the
specifics of what Access is storing in Jet tables. Now that would
sound like it oughtn't be an issue -- data is data, right? But it
*is* an issue, as Jet Replication was never fully stress-tested with
Access projects. What this means is that Jet Replication works fine
for tables and queries and not so well for forms/reports/etc.
2. There is no logical reason for a front end to be replicated. If
you need to update a front end, you just send a new one and copy it
over top of the old one, as the old one doesn't have any data in it
that the user needs to save. Replication is inherently two-way and
there is no need for there to be updates flowing back from replicas
of the front end. What happens is that you get lots of conflicts on
the Access objects, because, despite what you might think, there are
things saved in the forms, for instance (such as filters and sorts),
and those need to be reconciled.
3. This may sound like it's only a little higher level of conflicts
than you might conceivably have with your data tables, but it's not,
because starting with Access 2000, the method of storing the Access
project was markedly changed, from keeping a record in a system
table for each Access object, to keeping a *single* record for the
whole project, with a BLOB field storing THE ENTIRE ACCESS PROJECT
IN ONE FIELD. This would be analogous to having a single record in
your data table with a memo field that every user updated each time
they used the database -- imagine the conflicts and corruption that
would result from that! This is precisely what you are doing when
you replicate an Access front end, buying a massive number of
conflicting updates to a single field in one record, and the data in
that field is *enormously* complicated, so you're counting on every
synch successfully writing that field correctly.
The risk of replicating a front end may not be obvious in all cases
-- sometimes you can do it for a long time and nothing bad happens.
But when eventually something *does* go wrong, you risk losing the
whole Access project, corrupted beyond recovery and no longer able
to synch.
Is that worth the risk for the complete lack of any benefit that
comes with replicating a front end MDB?
This has been working fine for at least a year.
Sometime in the next year, or the year after that, or the year after
that, it will stop working.
Now
when I run synch now, it doesn't update my query. The query is
marked to replicate. In fact, the query on the replica is blank
and perfect at the design master. What can I do to fix this?
Try recreating the query in the design master, replicating it and
seeing if the new one works in the replica.
This is precisely the kind of symptom of corruption that would
happen with the Access project (though queries are not stored as
part of the Access project BLOB, so far as I'm aware) -- something
works one day and then it won't synch its changes. And then the
object doesn't work at all. And then the problem spreads to other
objects.
Split your app and get rid of replication on the front end. There is
really no other way to use replication reliably.
