What happens if users simultaneously synchronize replicas with hub replica

[rdemyan via AccessMonster.com]

I'm just starting to play with replication. It looks like it might work
fairly well for what I need.

I'm not in a good position to test what happens if two or more users try to
sync their replicas at the same time with the hub replica located on the
server.

Can someone who has experience with this provide me with some guidance. The
reason I ask is that I was thinking about having my app sync the local
replica with the server hub when the user closes the app (using code). But I
wasn't going to force the user to wait for a messagebox stating whether it
was sucessful or not, in case, it takes a long time. But if simultaneous
synchronization results in failure, then I'm not sure what to do. If an
error message doesn't display, then the user will merrily close the app and
be angry later when they find out that the syncing failed because of a
simultaneous synchronization failure.

So how does Access handle this situation?

Thanks.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200612/1

[ManningFan]

It's a better idea to replicate at alternating times. We replicate
every 10 minutes, with one database replicating on the 5's and one on
the 0's (i.e. one at 10:30, the other at 10:35, the first at 10:40,
etc...).

As for what would happen if they replicate in sync, I don't know.
There's a good possibility that you could end up with a record locking
issue.
rdemyan via AccessMonster.com wrote:

I'm just starting to play with replication. It looks like it might work
fairly well for what I need.

I'm not in a good position to test what happens if two or more users try to
sync their replicas at the same time with the hub replica located on the
server.

Can someone who has experience with this provide me with some guidance. The
reason I ask is that I was thinking about having my app sync the local
replica with the server hub when the user closes the app (using code). But I
wasn't going to force the user to wait for a messagebox stating whether it
was sucessful or not, in case, it takes a long time. But if simultaneous
synchronization results in failure, then I'm not sure what to do. If an
error message doesn't display, then the user will merrily close the app and
be angry later when they find out that the syncing failed because of a
simultaneous synchronization failure.

So how does Access handle this situation?

Thanks.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200612/1

[rdemyan via AccessMonster.com]

Thanks. The issues I have is a relatively slow connection and unfortunately
Access isn't multithreaded. So when you sync up every ten minutes, doesn't
your app pause while the syncing is occurring.

I wonder if it would be possible to have a second "synching" app launch
(perhaps hidden) that does the synching of the databases at regular times.
That might prevent the main app from pausing while
any synching was occuring from the main app.

Also, now that I think about it, it isn't really absolutely necessary that
the synching occur when the user closes the main app. Synching could occur
at a later time. My app doesn't typically require up-to-the-minute data.
But I guess the only issue would be if the user doesn't log in again for
quite some time. His/her updates wouldn't be picked up. The configuration I
was planning to use is a star configuration. I don't see how the server hub
back-end can sync with copies on user's local PCs.
ManningFan wrote:

>It's a better idea to replicate at alternating times. We replicate
every 10 minutes, with one database replicating on the 5's and one on
the 0's (i.e. one at 10:30, the other at 10:35, the first at 10:40,
etc...).

As for what would happen if they replicate in sync, I don't know.
There's a good possibility that you could end up with a record locking
issue.

>I'm just starting to play with replication. It looks like it might work
fairly well for what I need.

[quoted text clipped - 20 lines]

>Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200612/1

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200612/1

[ManningFan]

Then sync it on the hour or something. Every 2 hours, offsetting.

The main replication database can sync with any copy it can see, so it
depends on your network. If it can see the user's local PCs, it can
sync with it. However, I wouldn't put back-end databases on local PCs.
If anything I'd put the front end on their PC and keep the back end on
a server.

rdemyan via AccessMonster.com wrote:

>
Also, now that I think about it, it isn't really absolutely necessary that
the synching occur when the user closes the main app. Synching could occur
at a later time. My app doesn't typically require up-to-the-minute data.
But I guess the only issue would be if the user doesn't log in again for
quite some time. His/her updates wouldn't be picked up. The configuration I
was planning to use is a star configuration. I don't see how the server hub
back-end can sync with copies on user's local PCs.

[Bri]

rdemyan via AccessMonster.com wrote:

I'm just starting to play with replication. It looks like it might work
fairly well for what I need.

I'm not in a good position to test what happens if two or more users try to
sync their replicas at the same time with the hub replica located on the
server.

Can someone who has experience with this provide me with some guidance. The
reason I ask is that I was thinking about having my app sync the local
replica with the server hub when the user closes the app (using code). But I
wasn't going to force the user to wait for a messagebox stating whether it
was sucessful or not, in case, it takes a long time. But if simultaneous
synchronization results in failure, then I'm not sure what to do. If an
error message doesn't display, then the user will merrily close the app and
be angry later when they find out that the syncing failed because of a
simultaneous synchronization failure.

So how does Access handle this situation?

Thanks.

There are others here that are more familiar with the internals of
Replication than I, but one thing I do know is that syncing locks the
whole table that it is working with. If two processes want to lock a
table, then the first one will get it and the second one will either
retry or fail. If your connection is slow or you have a lot of data to
sync, then the lock will outlive the retrys and it fails.

We had enough problems with this that we schedule syncing for a specific
time that EVERYONE else stays out of the database completely. I
specified the two processes above without qualifying that they were
replication processes since it doesn't matter what the processes are. If
one is a sync and it locks the table you want to add data to, then your
data entry will fail.

Bottom line is that Replication is a touchy thing that has to be done
just right or it has problems. It is NOT the best solution for many of
the things it is being used for, in spite of MS claims of what it can do.
--
Bri