|
|
|
date: Tue, 13 Nov 2007 11:03:47 -0600,
group: microsoft.public.access.replication
back
Re: Error 3167 Record is deleted
David W. Fenton wrote:
> user@domain.invalid wrote in
> news:OJY2ubhJIHA.5860@TK2MSFTNGP04.phx.gbl:
>
>> Just got two different error 3167 record is deleted - two
>> different users of my app - both on the same day. And both of
>> them connect to the same replica on the server (3 groups of users
>> in 3 physical locations; these two are in the same location and
>> use the same server replica for sync)
>>
>> App is split front end/back end. About 25 laptops using
>> replicated back ends. They sync via computer control when the
>> program is started and they are connected to the LAN. Sync is
>> direct.
>>
>> One user had synced OK on 11/9, next time same day failed with
>> 3218 which seems to be a transient error. Then on Monday 11/12,
>> failed with a 3167.
>
> It's important to determine *why* you get error 3218. If there's
> really someone editing a table that has a synch on it, then that's
> one thing. If there isn't, then it's likely an indication of
> corruption. And it's important which partner replica in the exchange
> has the 3218 lock on it. In other words, don't treat it as
> transient, but diagnose it when it comes up, as it could be the
> first indication of a serious problem.
>
>> In my experience a 3167 is the "kiss of death" and the database is
>> toast. I have never been able to use compress and repair to make
>> such repairable. In this case the compress was not successful and
>> I got a new database db1_damaged.mdb as the result.
>>
>> Found several _conflict tables but all were empty except for the
>> MSysSchedule_conflict which had 6 records in it.
>
> What did those records say? Do you have scheduled synchs anywhere in
> your replica set? Keep in mind that indirect synchs are scheduled,
> even if you run them interactively.
>
>> Have not yet diagnosed the 2nd database.
>>
>> I have had replication in place since about June of this year.
>> Only one other 3167 instance a couple of months back.
>>
>> Suggestions on how to figure out the cause?
>
> Don't ignore error messages?
>
Yo David.
1)When I get a 3218 error from a sync that failed, can you tell me what
steps I can take to learn what caused it?
Bob
date: Tue, 13 Nov 2007 17:02:48 -0600
author: lid
Re: Error 3167 Record is deleted
user@domain.invalid wrote in
news:usuWVkkJIHA.4196@TK2MSFTNGP04.phx.gbl:
> When I get a 3218 error from a sync that failed, can you tell me
> what steps I can take to learn what caused it?
You should look in the relevant system tables and see what the full
record says. Not sure whether that one shows up in MSysConflicts or
somewhere else, though. The point is that the error record ought to
give you more information. And if it's 3218, it means one of the
tables or records are in use (and after looking in the system table
you should know which replica and which table, if not necessarily
which record), and then you can confirm that, yes, indeed, someone
is editing that table/record. If they aren't, then you've likely got
corruption in that replica.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
date: Wed, 14 Nov 2007 14:00:31 -0600
author: David W. Fenton lid
Re: Error 3167 Record is deleted; also more info on 3218 and 3460
errors
David W. Fenton wrote:
> user@domain.invalid wrote in
> news:usuWVkkJIHA.4196@TK2MSFTNGP04.phx.gbl:
>
>> When I get a 3218 error from a sync that failed, can you tell me
>> what steps I can take to learn what caused it?
>
> You should look in the relevant system tables and see what the full
> record says. Not sure whether that one shows up in MSysConflicts or
> somewhere else, though. The point is that the error record ought to
> give you more information. And if it's 3218, it means one of the
> tables or records are in use (and after looking in the system table
> you should know which replica and which table, if not necessarily
> which record), and then you can confirm that, yes, indeed, someone
> is editing that table/record. If they aren't, then you've likely got
> corruption in that replica.
>
I just checked the 3218 error on the only three instances for this one
user. All three show up in the MSysExchangeLog as "Cannot place a write
lock". Sounds like a legitimate conflict. It has occurred 52 out of
5226 sync attempts.
All the 3167's show up as
"An error occurred while using this member in the
replica set;UNKNOWN REASON (-1017)"
helpful, hun?
The other error I seem to get is 3460. Still looking for examples of it
in the system control tables. So far where my own log reports an error
3460 but nothing is posted in MSysExchangeLog. This has occurred 90 of
5226 sync attempts.
Error 3460 is "The operation you attempted conflicts with an existing
operation involving this member of the replica set"
date: Wed, 14 Nov 2007 16:10:05 -0600
author: lid
Re: Error 3167 Record is deleted; also more info on 3218 and 3460 errors
user@domain.invalid wrote in
news:u5orbswJIHA.5980@TK2MSFTNGP04.phx.gbl:
> David W. Fenton wrote:
>> user@domain.invalid wrote in
>> news:usuWVkkJIHA.4196@TK2MSFTNGP04.phx.gbl:
>>
>>> When I get a 3218 error from a sync that failed, can you tell me
>>> what steps I can take to learn what caused it?
>>
>> You should look in the relevant system tables and see what the
>> full record says. Not sure whether that one shows up in
>> MSysConflicts or somewhere else, though. The point is that the
>> error record ought to give you more information. And if it's
>> 3218, it means one of the tables or records are in use (and after
>> looking in the system table you should know which replica and
>> which table, if not necessarily which record), and then you can
>> confirm that, yes, indeed, someone is editing that table/record.
>> If they aren't, then you've likely got corruption in that
>> replica.
>>
> I just checked the 3218 error on the only three instances for this
> one user. All three show up in the MSysExchangeLog as "Cannot
> place a write lock". Sounds like a legitimate conflict. It has
> occurred 52 out of 5226 sync attempts.
It's not necessarily legitimate. You can't say unless you check to
see if anyone is using the replica in question at the time the error
is recorded. This has to be done when the error occurs. Remember,
this error can occur in non-replicated databases as a sign of
corruption.
> All the 3167's show up as
> "An error occurred while using this member in the
>
> replica set;UNKNOWN REASON (-1017)"
>
> helpful, hun?
I would strongly suspect corruption, and that the 3218 error is a
signal of it.
> The other error I seem to get is 3460. Still looking for examples
> of it in the system control tables. So far where my own log
> reports an error 3460 but nothing is posted in MSysExchangeLog.
> This has occurred 90 of 5226 sync attempts.
>
> Error 3460 is "The operation you attempted conflicts with an
> existing operation involving this member of the replica set"
It sounds to me as though you have significant problems in your
replica set. I just checked two different replica sets of mine and I
don't have anything close to that number of errors. What are the
reason codes given for each of these errors?
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
date: Thu, 15 Nov 2007 15:59:00 -0600
author: David W. Fenton lid
Re: Error 3167 Record is deleted; also more info on 3218 and 3460
errors
David W. Fenton wrote:
> user@domain.invalid wrote in
> news:u5orbswJIHA.5980@TK2MSFTNGP04.phx.gbl:
>
>> David W. Fenton wrote:
>>> user@domain.invalid wrote in
>>> news:usuWVkkJIHA.4196@TK2MSFTNGP04.phx.gbl:
>>>
>>>> When I get a 3218 error from a sync that failed, can you tell me
>>>> what steps I can take to learn what caused it?
>>> You should look in the relevant system tables and see what the
>>> full record says. Not sure whether that one shows up in
>>> MSysConflicts or somewhere else, though. The point is that the
>>> error record ought to give you more information. And if it's
>>> 3218, it means one of the tables or records are in use (and after
>>> looking in the system table you should know which replica and
>>> which table, if not necessarily which record), and then you can
>>> confirm that, yes, indeed, someone is editing that table/record.
>>> If they aren't, then you've likely got corruption in that
>>> replica.
>>>
>> I just checked the 3218 error on the only three instances for this
>> one user. All three show up in the MSysExchangeLog as "Cannot
>> place a write lock". Sounds like a legitimate conflict. It has
>> occurred 52 out of 5226 sync attempts.
>
> It's not necessarily legitimate. You can't say unless you check to
> see if anyone is using the replica in question at the time the error
> is recorded. This has to be done when the error occurs. Remember,
> this error can occur in non-replicated databases as a sign of
> corruption.
>
>> All the 3167's show up as
>> "An error occurred while using this member in the
>>
>> replica set;UNKNOWN REASON (-1017)"
>>
>> helpful, hun?
>
> I would strongly suspect corruption, and that the 3218 error is a
> signal of it.
>
>> The other error I seem to get is 3460. Still looking for examples
>> of it in the system control tables. So far where my own log
>> reports an error 3460 but nothing is posted in MSysExchangeLog.
>> This has occurred 90 of 5226 sync attempts.
>>
>> Error 3460 is "The operation you attempted conflicts with an
>> existing operation involving this member of the replica set"
>
> It sounds to me as though you have significant problems in your
> replica set. I just checked two different replica sets of mine and I
> don't have anything close to that number of errors. What are the
> reason codes given for each of these errors?
>
For the error reported to VBA as 3218, I find in MSYsExchangeLog reason
code 25 and reasondescription "Cannot place a write lock".
For the error reported to VBA as 3460, as I mentioned earlier, I do not
see any corresponding entry in MSysExchangeLog. It appears it does not
get that far.
Bob
date: Thu, 15 Nov 2007 16:30:56 -0600
author: lid
|
|
