Re: Indirect Rep & Search Key Not Found Error

From: Cheval (anonymous_at_discussions.microsoft.com)
Date: 08/06/04 

Date: Fri, 6 Aug 2004 15:09:17 -0700

Ok I believe we have found the problem with our corruption
and Search Key... Error and it's not a problem with Access
2003, well not entirely, I'll explain.

We had the physical network checked and tested a couple of
weeks ago and some problems with the cabling was found and
fixed. They got back to us yesterday with the report;
there were other problems. Apparently under certain
conditions, the network would drop out for certain
computers and need to be re-established. So if Access was
in the middle of a write to the backend in standard
operation or during a replication, the file could get
corrupted. Ok fair enough, the Access data engine is on
the client machine so it has to write directly to the
file, and an interruption to that would likely corrupt the
file.

Now the thing I find odd is this. Is Replication on Access
2003 so finicky that only the replication part of the file
gets corrupt only and why did Access 97 handle this fine?
Is Access 2003 just not forgiving at all?

So anyway the moral of the story is, check the physical
network if your replication goes haywire in Access 2003.
If you have ruled out everything else (the MS guy says
make sure on errors that you set _all_ objects to equal
nothing) and if it randomly continues, create indirect
replica farms on every PC for your sanity sake. I've not
had to re-create the whole replica set for a week now, and
believe me; that feels good. :D

>-----Original Message-----
>We don't know what's wrong either. We updated every
>machine to the latest Jet service pack the first time
this
>happened. We've got the latest Jet, MDAC, Office 2003
SP1,
>Windows updates, professionally checked the physical
>network, externally verified front end application code
>and scratched my head twice!
>
>Last night I created replica farms on every machine in
the
>network, because yesterday the Hub Backend that the fixed
>location desktop users use, became corrupt. I think there
>may be a rogue desktop machine on the network causing the
>corruption problem, as the replica users were happy to
>sync with the every other replica in the network. If my
>suspicions are correct, the dodgy desktop machine(s) (I
>hope there's only 1) will corrupt its own replica in the
>next few days. I'd much rather fix one machine's replica,
>rather than recreate the whole replica set each time this
>happens.
>
>>-----Original Message-----
>>I am not sure what is wrong. Though I would highly
>recommend (as Mark Hyland
>>does, in a different thread here) to update to the
latest
>Jet version
>>service pack and make sure all machines are at the same
>level.
>>
>>
>>--
>>MichKa [MS]
>>NLS Collation/Locale/Keyboard Development
>>Globalization Infrastructure and Font Technologies
>>Windows International Division
>>
>>This posting is provided "AS IS" with
>>no warranties, and confers no rights.
>>
>>
>>"Cheval" <anonymous@discussions.microsoft.com> wrote in
>message
>>news:806d01c477ca$ffa04850$a401280a@phx.gbl...
>>> How do you tell if the farm is being used or not?
>>>
>>> From a look at the log, it reads to me as the server
>>> synchronizer indirectly synchronized with other
>>> synchronizers, but within the replicas it managed, it
>>> syncronized directly. Should this be the case or have
we
>>> set it up incorrectly?
>>>
>>> At 9am we tried sync'ing the Design Master with the Hub
>>> Backend. When that failed, we opened the backend
>manually
>>> and tried a direct replication with the Design Master
>>> which also failed with the Error.
>>>
>>> FYI: One thing to note. I received an email from the
>>> Microsoft support person, mentioning
>>> (http://support.microsoft.com/?id=321076 Updated
version
>>> of the Microsoft Jet 4.0 Service Pack 8 replication
>files
>>> is available in the Download Center) this link. Our
>files
>>> that matched in the Replication Manager were of an
older
>>> version number. I ran the patch Saturday night on the
>>> server and will likewise do on the user laptops,
Monday.
>>> We also installed Office 2003 SP1 on Friday evening.
>>>
>>> >-----Original Message-----
>>> >-1601 is the internal code for the "key not found"
>error.
>>> The indivation
>>> >about a DIRECT sync indicates that an indirect sync
>with
>>> the synchronizer
>>> >was not happening there -- thus the farm was not being
>>> used?
>>> >
>>> >
>>> >--
>>> >MichKa [MS]
>>> >NLS Collation/Locale/Keyboard Development
>>> >Globalization Infrastructure and Font Technologies
>>> >Windows International Division
>>> >
>>> >This posting is provided "AS IS" with
>>> >no warranties, and confers no rights.
>>> >
>>> >
>>> >
>>> >"Cheval" <anonymous@discussions.microsoft.com> wrote
in
>>> message
>>> >news:6e9601c475b6$37b56930$a501280a@phx.gbl...
>>> >> On the server, which was managering the Hub Backend
>and
>>> >> the Design Master at the time had the following
>hourly
>>> >> scheduled events:
>>> >>
>>> >> The Sync Log says the same as the MSysExhangeLog.
All
>>> was
>>> >> working fine until 8am in the morning, then at the
>9am
>>> the
>>> >> Reason field contained the text "An error occurred
>while
>>> >> using this member in the replica set;UNKNOWN REASON
>(-
>>> >> 1601)" and that's how the rest of the scheduled
>events
>>> >> repeat.
>>> >>
>>> >> When we come on the scene for a manual replication
at
>>> >> around 11am, it reports "Synchronizer send failure;
>>> >> DIRECT : No suitable synchronizer address ; FS :
>>> >> Synchronizer send failure;"
>>> >>
>>> >> Is this what you wanted?
>>> >>
>>> >> >-----Original Message-----
>>> >> >I meant the ones that are failing? What do the
logs
>and
>>> >> the exchange tables
>>> >> >say about the ones that fail?
>>> >> >
>>> >> >
>>> >> >--
>>> >> >MichKa [MS]
>>> >> >NLS Collation/Locale/Keyboard Development
>>> >> >Globalization Infrastructure and Font Technologies
>>> >> >Windows International Division
>>> >> >
>>> >> >This posting is provided "AS IS" with
>>> >> >no warranties, and confers no rights.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >"Cheval" <anonymous@discussions.microsoft.com>
>wrote in
>>> >> message
>>> >> >news:628f01c474f1$3c63cb90$a501280a@phx.gbl...
>>> >> >> Replica farms on both ends? No, we only have one
>on
>>> the
>>> >> >> server. We'll put one on each users laptop today.
>>> >> >>
>>> >> >> Verify indirect is happening? Yes, I have
verified
>>> that
>>> >> >> the Syncs are indirect. The message and data file
>>> >> passing
>>> >> >> looked to be working well.
>>> >> >>
>>> >> >> >-----Original Message-----
>>> >> >> >I do not see that you have set up replica farms
>on
>>> both
>>> >> >> ends of the indirect
>>> >> >> >syncs, or that you have verified in the logs
that
>>> the
>>> >> >> syncs have been
>>> >> >> >indirect. Have both of these things been done?
>>> >> >> >
>>> >> >> >
>>> >> >> >--
>>> >> >> >MichKa [MS]
>>> >> >> >NLS Collation/Locale/Keyboard Development
>>> >> >> >Globalization Infrastructure and Font
>Technologies
>>> >> >> >Windows International Division
>>> >> >> >
>>> >> >> >This posting is provided "AS IS" with
>>> >> >> >no warranties, and confers no rights.
>>> >> >> >
>>> >> >> >
>>> >> >> >"Cheval" <anonymous@discussions.microsoft.com>
>>> wrote in
>>> >> >> message
>>> >> >> >news:560901c4743f$cffa1010$a301280a@phx.gbl...
>>> >> >> >> Background info: In case you haven't read our
>>> >> continued
>>> >> >> >> problems with Access 2003, Replication and
>>> >> the "Search
>>> >> >> Key
>>> >> >> >> Not Found" error; here is a summary below.
>>> >> >> >>
>>> >> >> >> We have a Design Master and Hub Backend on the
>>> >> server.
>>> >> >> >> Local users connect their Front Ends through
>the
>>> >> local
>>> >> >> LAN
>>> >> >> >> to the hub backend. The laptop users have full
>>> global
>>> >> >> >> replicas on their laptops and replicate their
>>> >> changes to
>>> >> >> >> the hub backend, through the local LAN or via
a
>>> VPN
>>> >> >> >> connection. For a year or so with Access97 we
>>> >> replicated
>>> >> >> >> via direct replication and everything (while a
>>> little
>>> >> >> slow
>>> >> >> >> for the VPN users) worked perfectly. Then we
>>> >> upgraded to
>>> >> >> >> Office 2003. Within a week and a half, we had
>>> users
>>> >> >> >> reporting the "Search Key Not Found" error.
If
>we
>>> >> >> created
>>> >> >> >> a new replica for them and manually copied
>their
>>> data
>>> >> >> over
>>> >> >> >> quick enough, it was fix for a bit. If we
>waited a
>>> >> day,
>>> >> >> >> then the Hub Backend would report this error
as
>>> well
>>> >> >> when
>>> >> >> >> replicating every where and we would have to
>>> recreate
>>> >> >> the
>>> >> >> >> whole replica set, as it spread and infected
>all
>>> >> >> >> replica's. After recreating the whole replica
>set
>>> a
>>> >> good
>>> >> >> >> number of times (the last time was the next
day
>>> after
>>> >> >> >> recreating it) we converted the replica set
>back
>>> >> into a
>>> >> >> >> standard MDB file backend. We got network
>people
>>> out
>>> >> to
>>> >> >> >> investigate the physical network and while
they
>>> found
>>> >> >> some
>>> >> >> >> problem cables, which were replaced, nothing
>>> serious
>>> >> was
>>> >> >> >> found that would result in bad or lost
packets.
>>> I've
>>> >> >> also
>>> >> >> >> had our Front End checked for coding errors
and
>>> there
>>> >> >> were
>>> >> >> >> cases that on some errors, we were not
>releasing
>>> some
>>> >> >> >> objects, so that's also now fixed. Then
>following
>>> >> some
>>> >> >> >> advice we setup Office 2000 Developer's
>>> Replication
>>> >> >> >> Manager and things looked good again... for a
>week
>>> >> and a
>>> >> >> >> half that is... Today the Hub Backend and
>Design
>>> >> Master
>>> >> >> >> reports the error, which means again
recreating
>>> the
>>> >> >> >> replica set or go back to non-replicaton
again.
>>> One
>>> >> >> finial
>>> >> >> >> thing that may tempt us in recreating the
>replica
>>> >> set is
>>> >> >> >> that I noticed Office 2003 SP1 released
today.
>We
>>> >> >> usually
>>> >> >> >> wait until the press and others give us the
>guinea
>>> >> pig
>>> >> >> >> heads up, but we're desperate. So I'll let you
>>> know
>>> >> the
>>> >> >> >> outcome of another replica set recreation.
>Sooner
>>> if
>>> >> >> >> things to bad again, later if things go well.
>So I
>>> >> hope
>>> >> >> >> not to be sending another message for some
>>> time. :)
>>> >> >> >>
>>> >> >> >> So from all that can anyone help with
>determining
>>> >> what
>>> >> >> is
>>> >> >> >> causing this corrupting to report this error?
>>> >> >> >>
>>> >> >> >> Unfortunately, the only thing to have changed
>is
>>> >> Office
>>> >> >> >> and we can't go back. Office 97 worked, Office
>>> 2003
>>> >> >> >> doesn't. Has anyone else experienced similar
>>> >> problems or
>>> >> >> >> solved anything like this?
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >> >.
>>> >> >> >
>>> >> >
>>> >> >
>>> >> >.
>>> >> >
>>> >
>>> >
>>> >.
>>> >
>>
>>
>>.
>>
>.
>