Working in a well controlled company environment, people here decided
recently to use replicated applications, not only to achieve mobility, but
mainly because working with Access 2003 XP directly on the cor****ate
network
is too slow. Apps are f/e - b/e Access applications. Keeping the master
b/e
in the developer PC, the first replication b/e placed on the network is
the
concentrator and is used for further b/e rep generation for each of the
user
PCs.
I do have some Access experience, but replication is relatively new to me;
as a matter of fact, I still don’t feel secure. One of the problems is
that
the concentrator fails to synchronize modifications in the table structure
of
the master b/e. The only way out I see is to kill and substitute the
concentrator by a new rep from the master b/e. Then kill all the reps in
each
user PC and create new reps from the concentrator. Last time when sync
problems popped up all over the place, I got one step further, and tried
to
get rid of the problem creating a fresh master b/e, copying the whole
structure into a new normal dB, uploading all data from the master b/e and
then transformed it into a replicated dB, starting replication from zero
–
but apparently without effectively solving the problem. This procedure is
not
only ***bersome but users re****ted some data loss. After that, there were
sync problems, and it took some time to stabilize again.
Originally there were a few macros and forms in the b/e, I changed this on
the master b/e. But sync does not get rid of the additional stuff, the
same
way table changes will not rep. The f/e originally where replicated too, I
changed this also.
Do you have on idea what could be wrong with this system? When I
experiment
replication on my home PC, it does work fine. The problem is that it fails
in
the cor****ate environment. The difference is that the experiments use
‘virgin’ reps, while the cor****ate reps are heavy duty.
Thank you for any suggestions
--
jean marhucolle
|
