Synchronisation problem - file "|" locked

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Peter Johal - 14 Aug 2005 15:07 GMT

We have a configuration where 10-15 replica's synchronize with one master.
We have been using this configuration for a couple of years now, without
problems.

Three weeks ago we started having problems, when replica's synchronized with
the master. The replica gave te message that the file name "|" (pipe symbol)
was locked and it asked ignore or retry. Choosing ignore made the
synchronisation fail. We started getting this on multiple replica's, but not
on all of them. On some the synchronisation works fine. If we make a new
replica it synchronizes ok.

We have not been able to find the problem. Does anyone have any idea?

We use access 2002 with a access 2000 format database file.

Peter J.

Reply to this Message

David W. Fenton - 14 Aug 2005 21:27 GMT

> We have a configuration where 10-15 replica's synchronize with one
> master. We have been using this configuration for a couple of
[quoted text clipped - 12 lines]
>
> We use access 2002 with a access 2000 format database file.

I assume you've checked the system tables for any clues about what
file it might be that's somehow not getting into the error message
(the pipe symbol is obviously a placeholder that's supposed to be
replaced by a file name when the error message is displayed)?

You say you're synching with the "master." Do you mean the Design
Master? If so, I have to ask why you're using it as a
synchronization hub? I would never do that. I would also look to see
if there are problems with the LDB file for that hub that you're
synchronizing with (DM or not), and see if it's managed by a
synchronizer (you don't say if you're doing direct or indirect
synchronization). I'd also check file system permissions on the
folder where your hub is located. That could have changed and could
be leading to problems.

Other than that, I don't have any suggestions.

Signature

David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Reply to this Message

Peter Johal - 16 Aug 2005 22:17 GMT

David,

Thanks for your ideas.

The master I talked about is the Design Master. The replica's run on local
PC's, while the design master is on the network. No data is being
manipulated directly on the master, only on the replica's. So the
synchronisation is direct and the master acts as a hub.
This situation existed since before I came to work here. I suppose it was
set up this way to avoid transferring large amounts of data across the
network, since access is not client-server.

You say "I would never do that". Do you mean that we should not use a design
master as a synchronisation hub. If so, why not.

We see no problems with the ldb and we cannot find problems with tables etc.
File system permissions have not changed.

The problem we face is that data has been entered in a number of replica's
that should be synchronized with the design master, so then distributed
accross all replica's. The only solution we have at the moment is a
comparison tool we have written that generates logs and dml statements we
can execute against a valid replica.

Peter Johal

>> We have a configuration where 10-15 replica's synchronize with one
>> master. We have been using this configuration for a couple of
[quoted text clipped - 29 lines]
>
> Other than that, I don't have any suggestions.

Reply to this Message

David W. Fenton - 16 Aug 2005 22:28 GMT

> The master I talked about is the Design Master. The replica's run
> on local PC's, while the design master is on the network. No data
[quoted text clipped - 6 lines]
> You say "I would never do that". Do you mean that we should not
> use a design master as a synchronisation hub. If so, why not.

It's the same reason you don't use it for production use as your
edited MDB file -- there are too many things that can go wrong and
you could lose it.

The Design Master is like your source code -- you put it aside and
archive it, and pull it out only when needed. It should never be
used for any daily production task of any kind.

You should have on your server the Design Master, your edited MDB
and your synchronization hub. That's the minimum for the "home
office." Of course, the Design Master can be anywhere, but I would
never double up functionality of the Design Master with one of the
other functions.

> We see no problems with the ldb. . .

Well, what have you tested? Have you tried unmanaging the hub and
then attempting to delete the LDB file? Have you tried shutting down
the synchronizer and attempting to delete the LDB file? Or is the
LDB file constantly there? If it is always there, then it may have
corrupt entries in it (not uncommon, and usually something that Jet
just ignores). Or, there could be a Windows file lock on it, due to
an improperly logged out user somewhere (though the only user that
should ever have your hub replica open is the one under which the
Jet synchronizer is running).

> . . . and we cannot find problems with
> tables etc. File system permissions have not changed.

Are you absolutely certain about this? It is possible that the file
permissions on the folder have *not* changed, but that group
membership of the user that they synchronizer is running under has
changed, and this means that user logon is inheriting different
permissions.

Or maybe you're using a different user logon for running the
synchronizer, a user with different permissions.

> The problem we face is that data has been entered in a number of
> replica's that should be synchronized with the design master, so
> then distributed accross all replica's. The only solution we have
> at the moment is a comparison tool we have written that generates
> logs and dml statements we can execute against a valid replica.

Have you tried creating a new replica and transferring design master
status to it, thus demoting your current hub from DM to a regular
replica? I don't know what that might accomplish, but it's worth a
try.

Also, try unmanaging your hub replica and then re-managing it. That
may be part of the problem.

Of course, I;m assuming here that you're using indirect replication,
which might very well be an invalid assumption all around.

Signature

David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Reply to this Message

Peter Johal - 18 Aug 2005 20:49 GMT

David,

Thank you again for your suggestions. They got me thinking. Your explanation
of the design master was very helpful and your suggestion to seperate it
from the hub function is a good one.

We only use direct synchronisation. We do not use a synchronisation manager
or the replication manager.
The ldb's all disappear for each replica when everyone has left the
database.

And I know for sure file permissions are not the problem. I replicated a new
db to my local PC and copied a "faulty" replica from another machine. And
synchronized the two locally. I got the same message.

We have not tried demoting the design master yet, but we might.

Greetz,

Peter

>> The master I talked about is the Design Master. The replica's run
>> on local PC's, while the design master is on the network. No data
[quoted text clipped - 61 lines]
> Of course, I;m assuming here that you're using indirect replication,
> which might very well be an invalid assumption all around.

Reply to this Message