File Sharing Lock Error screws up syncing and resyncing

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

rdemyan@hotmail.com - 17 Dec 2006 01:32 GMT

I'm still learning about replication and am playing around with it.
Here's the scenario. I have a hub replica, a laptop replica and a
desktop replica.

1) On the laptop replica, I deleted 130,000+ rows from a back-end
table. I then tried to sync the laptop replica with the hub replica.
Took a while and then the following error:

Error 3052 "File Sharing lock count exceeded. Increase MaxLockPerFle
registry entry".

2) I then tried to sync again and I got a message back from my code
that the sync was successful.

3) I then tried to sync my desktop replica up with the hub. Twenty
seconds later I got a sync successful message. I checked the table,
which should have been empty, but in fact has 30,744 rows in it???!

4) I then checked the hub replica. It has 26,493 records in it.

5) I tried resyncing everything again, multiple times and here is what
I am left with:

Laptop Replica: table has 0 rows (this is the correct number)

Hub Replica: table has 30,744 rows

Desktop Replica: table has 26,493 rows

Further syncing does not change these numbers. It's as though
everything got screwed up and the syncing process has lost it's point
of reference in order to get everything correct.

What the heck happened here??

Thanks for any responses, suggestions, insight

Reply to this Message

rdemyan@hotmail.com - 17 Dec 2006 19:05 GMT

I discovered how to minimize the possibility that this error will occur
in the future, but am still puzzled that these backends all had
different number of records after synchronization.

I added the following line of code prior to synchronization:

DBEngine.SetOption dbMaxLocksPerFile, 200000

> I'm still learning about replication and am playing around with it.
> Here's the scenario. I have a hub replica, a laptop replica and a
[quoted text clipped - 32 lines]
>
> Thanks for any responses, suggestions, insight

Reply to this Message

David W. Fenton - 18 Dec 2006 05:45 GMT

> I discovered how to minimize the possibility that this error will
> occur in the future, but am still puzzled that these backends all
[quoted text clipped - 3 lines]
>
> DBEngine.SetOption dbMaxLocksPerFile, 200000

I don't know why your replicas got screwed up, but isn't deleting
all the records an operation that isn't going to happen in
production use? If it *is*, then replicaion is simply not viable, as
you'll end up with horridly bloated replicas with hug MSysTombstone
tables.

Signature

David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Reply to this Message

rdemyan@hotmail.com - 18 Dec 2006 07:45 GMT

For some of my more important tables, I have included backup tables in
the back-end file. When the data entry person is thinking about
possibly changing some data in a table, I have them make a backup of
the table. Then if they screw it up, they can restore the backup table
and not have to go out and restore the back-end file.

The problem is this was all coded using Delete *..... to clear the
backup table and then an Append query to fill the backup table.

I'm currently in the process of recoding this as an "incremental
backup". So no Delete *.
It's actually working very well. When none of the data is different
between the backup and the main table, there is absolutely no bloat.
Even when there are small differences there is virtually no difference
in the backend file size.

> > I discovered how to minimize the possibility that this error will
> > occur in the future, but am still puzzled that these backends all
[quoted text clipped - 13 lines]
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/

Reply to this Message

David W. Fenton - 18 Dec 2006 20:17 GMT

> For some of my more important tables, I have included backup
> tables in the back-end file. When the data entry person is
[quoted text clipped - 12 lines]
> absolutely no bloat. Even when there are small differences there
> is virtually no difference in the backend file size.

There is no reason to replicate the backup table. Indeed, it
shouldn't be replicated.

I never put any temporary tables in my back ends, replicated or not.
I always use a tmp.mdb stored in the same directory as the front end
that has all the temporary tables in it. This way, it doesn't really
matter if it bloats.

Signature

David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Reply to this Message

rdemyan@hotmail.com - 17 Dec 2006 19:44 GMT

Reply to this Message

David W. Fenton - 18 Dec 2006 05:44 GMT

> I'm still learning about replication and am playing around with
> it. Here's the scenario. I have a hub replica, a laptop replica
[quoted text clipped - 31 lines]
>
> What the heck happened here??

Did you follow the instructions for increasing the MaxLocksPerFile
registry entry before attempting your next synch?

Signature

David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Reply to this Message