Re: UNKNOWN REASON (-1017)

Thank you, as ever, for your detailed response.

"David W. Fenton" wrote:

> =?Utf-8?B?T25kaW5l?= <Ondine@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> news:EA84F436-C1FF-49C4-A93F-0C4337F5C18C@xxxxxxxxxxxxx:
>
> > My experience today was no more satisfactory. I couldn't find any
> > obvious signs of corruption in the data causing the error (on a
> > laptop), but when I tried to compact/repair I got a message
> > telling me that the data was already opened by x on computer y
> > etc. Of course I was the only user with the database open. . . .
>
> That kind of error generally indicates a problem with the LDB file,
> or, sometimes with internal housekeeping structures within the
> database. This will *not* show up as corrupted data at all, as it
> has nothing to do with the data, but with the header structures that
> define the database file.
>
> This is the kind of thing that Peter Miller at PKSolutions.com is
> likely to be able to help you with. You would need a copy of the
> replica before it lost replicability, however, to get anything you
> don't already have.

Unfortunately I didn't check the msysConflicts table yesterday, which
usually has some message about corrupted data, not sure whether that would
have thrown much light on this however.
>
> []
>
> > The only thing I could do was to use the data in
> > newdata_damaged.mdb as the new data file and recreate a design
> > master and all the replicas. . . .
>
> That's not at *all* the only thing you could have done. You could
> have gone through the damaged replica and "manually" applied the
> changes that hadn't been synched to a working replica. To do this,
> it helps to have date stamps in your records, but you can also use
> the generation fields in the records to figure out which records
> have been changed/added without having to compare each record
> field-by-field to the records in a working replica.
>
> It's a lot of work, but it's usually easier than recreating the full
> replica sets.
>
I accept this, but since there is only one user working remotely, I decided
to take this route because I was under time pressure: he was off on another
trip that evening. Also with around 40 tables it would have been a long job.

> > . . . Fortunately virtually all the
> > updates since the last sync had been carried out on the remote
> > laptop so I was spared manual data merging. As far as tracing the
> > source of the corruption, my client could only tell me that he was
> > amending a record and was then unable to close the form having
> > received a message saying 'Record is deleted' - always a bad sign.
>
> Are memo fields involved? Are you running scheduled synchs in the
> background while the user is editing?

There is one memo field in the app, which I will convert to text, but it is
hardly used and would not have been involved when he was using that
particular form. I am running scheduled synchs every 15 minutes - the only
reason I did this was to ensure that the main data file was updated as soon
as possible after he reconnects to the network, and also so that his local
data will be as up to date as possible each time he leaves the network and
goes off.

However, I want to stress that when all this happened - the error and during
all the period between the last sync and the time when he couldn't sync, he
was out of the country and not networked, he was working on his local data
and so no live syncs were taking place. (Although would putting the data
changes into the drop-box count?)
>
> > The frightening thing is that having had a series of major data
> > corruption issues with this client I moved from direct to indirect
> > replication and they purchased all new equipment. So the laptop
> > is brand new. All has been going well since the end of May and I
> > thought my troubles were over. The client is, quite
> > understandably, hopping mad and I am really fed up. I don't know
> > what else to do to be quite honest. . . .
>
> It sounds like a network problem, just like the kind that cause
> corruption in non-replicated databases. See:
>
> http://www.granite.ab.ca/access/corruptmdbs.htm
>
Can it be a network problem if the corruption occurs when he is not
connected?? I wouldn't have thought so! However, since this is repeating a
problem which happened with his old equipment and server pc and he also has
updated software then the only common factor is the network - and the user of
course, who I suspect is prone to allowing his battery to run down, and does
other maverick things which I have never known a client to do - although
would *never* admit to it.

> > . . . I have been advised to
> > migrate to MSDN, i.e. sql server desktop, but this would be a
> > steep learning curve as I don't really know anything about sequel
> > replication. There's no one at the client site who would have a
> > clue about administering a SQL database.
>
> Fix the problems in the network, as Access is not the only program
> that can have its data corrupted by dodgy networking environments.

See above re the network - he wasn't on it when the corruption occured.
>
> > I am reaching the end of my tether with this - if anyone has any
> > advice, or can pass on the name of an Access Replication whizz kid
> > in the London area I would be eternally grateful.
>
> First of all, assure your client that this is not a replication
> issue at all -- it's a network or software configuration issue. The
> first thing I'd look at is the server software and the software
> running on the laptop that experienced the corruption.
>
Can you give me any clues as to what could be wrong with the software on the
laptop? As stated, it is a brand new Sony Viao with the latest MS Office
service packs and updated Jet files.

> Again, THIS IS NOT A REPLICATION PROBLEM.
>
> It is NOT AN ACCESS PROBLEM.
>
> It is a problem with the operating environment in which you're
> running your replicated Access application.
>
> And it's a bitch to troubleshoot!
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc
>

Regards

Ondine.
.

Relevant Pages

  • Re: Intermittant 3167 error/indexing problem
    ... risk of corruption. ... Network drivers can get upgraded/downgraded. ... Indirect synchs between a replica that is being edited? ... The synch should only happen when the edited replica is ...
    (microsoft.public.access.replication)
  • Re: Intermittant 3167 error/indexing problem
    ... compacted and repaired the back-end data file on the server but ... the replicas, and was not just specific to the corrupted replica. ... The client networking environment is unreliable or the application ... to corruption on a regular basis. ...
    (microsoft.public.access.replication)
  • Re: UNKNOWN REASON (-1017)
    ... replica before it lost replicability, however, to get anything you ... > laptop so I was spared manual data merging. ... > source of the corruption, my client could only tell me that he was ...
    (microsoft.public.access.replication)
  • Re: Question about potential for corruption when doing direct sync over a WAN
    ... As I understand it, the replica ... that if the link breaks or disconnects, that corruption can ... of database corruption on laptop based replicas. ... I have a sync button on the main menu. ...
    (microsoft.public.access.replication)
  • Re: Intermittant 3167 error/indexing problem
    ... xp) who sporadically suffers from data corruption. ... That sounds like a corrupted memo field pointer. ... problem whereby the client will on occasion go to open a record ... is, you probably need to recreate your entire replica set, as it ...
    (microsoft.public.access.replication)