Re: Bi-directional synchroniszation not working

Once again, thank you for all the comments.

I had thought that the setup I inherited was a standard set up and thats why
I use these terms, "Base folder" and so on. So here's my setup:

A Hub folder, inside is the main .mdb to which everyone synchronises with.
A Design folder, inside is the Design Master.
A Base folder, inside is a replica with a full complement of records.
A Backup folder, inside are replicas with scheduled synchs, Daily and Weekly.
Then 20 replicas on Desktop PC's (LAN) setup as Direct synchronisation and 6
Laptop users (WAN) with Indirect synchronisation.

All the Direct synch users access their local replica via forms I and my
predecessor have written. They update a projects details on their PC.. "Met
Architect on site, discussed changes." press the Synch Now button and that
goes to the Hub. Everyone who opens their form synchronizes to get the
latest data. Does some editing typically as above, synchronizes again to
give everyone their latest changes.

The project number is doled out using a form that allocates an incremental
project number from a non-replicated table on the hub (the main synchroniser
db), they get to chose the project name only. that project number then goes
into the main Project table which is replicated. Therefore the reps out on
the road have to be online to receive a project number so no duplicates can
be created.

If, as Jackson MacDonald implied, that most people carry on without being
able to tell which is the Base replica can I just ignore it and let MS
Replication Manager sort it out, ie decide on its own which has the lowest
Replica ID and use that as the Base or do I have to assign it?


David W. Fenton wrote:
I've been checking for conflicts and nothing ever comes up and
there aren't any dead replicas. I'm wondering if it could be a
[quoted text clipped - 5 lines]
that won't replicate is additions to the main table. Could it be
the auto generated number is causing the problem?

How could it be causing a problem?

If there were duplicates generated, then there'd be a conflict (Jet
4.0) or replication error (Jet 3.5).

You might want to see if you can match up any of the GUIDs of the
missing records to records in the MSysTombstones table. If they are
there, that proves that deletions in some replica are what is
causing the data to disappear.


--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200604/1
.