Re: UNKNOWN REASON (-1017)

Tech-Archive recommends: Fix windows errors by optimizing your registry



"David W. Fenton" wrote:

> =?Utf-8?B?T25kaW5l?= <Ondine@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> news:B1708CDC-6EE6-4039-8E72-D79A5CAACB0C@xxxxxxxxxxxxx:
>
> > "David W. Fenton" wrote:
> >
> >> []
> >>
> >> > . . . 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.
>
> Well, two things:
>
> 1. if you're doing scheduled synchs on data that's being edited
> live, then your memo fields need to be edited UNBOUND, because if a
> synch takes place while the memo field is being edited, the memo
> field (and the record it is in) can be lost. Another thing to
> consider which can minimize data loss from corrupted memos is to put
> the memos in their own table, rather than storing them in another
> table. That way, if a memo field pointer gets corrutped, only the
> memo data will be lost, and not any of the rest of the data for that
> record.

I take your point re memo fields, and in this case the best option is to
convert them (it, actually) to simple text fields. It won't be causing that
problem however because they have only used that field in four records in the
entire 3 years they have had the database (and not for memo-length strings)
>
> 2. Scheduled synchs to do not make any sense as the solution to the
> forgetful users problem. Instead, when the app starts up, check to
> see if some file on the network exists, and ask the user if he wants
> to synch now if the connection is there. Do the same on exit (you
> won't need to check again, just set a flag from the opening text
> that can be checked on close). Of course, I'd also suggest that you
> also switch to the LAN copy of the back end when the user is
> connected to the LAN. That can be part of the same routine, which
> for opening would do these tasks:
>
> A. check if the LAN connection is there (Dir() should suffice)
>
> B. if so, check if the tables are already linked to the LAN data.
> If so, do nothing.
>
> C. if not, then prompt the user and ask if he wants to synch his
> data file and start using the LAN copy. I'd offer those as
> independent choices, with the default to do both, but with the
> ability to choose only one or the other (or neither). I'd do that
> with check boxes defaulting to TRUE, and an OK and CANCEL button.
>
> For the exit routine, if the users is connected to the LAN, ask if
> he wants to prepare for travelling and synch the data and switch to
> the local replica. You should also provide a UI for doing this
> manually without prompting.

I do already have a similar routine to the one you describe for checking for
a network connection, checking the current table links and connecting if
necessary (or to the local data where appropriate). Incorporating a synch at
that point would be useful, however I'm using Replication Manager now and am
not sure how that can be manipulated from within my app - could you help me
with this?
Also, I was under the impression (from other posts/advice on this group)
that running scheduled syncs was not problematic, and in fact was
recommended. Is this not correct?
>
> > 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?)
>
> This is more evidence for my belief that the problem had nothing to
> do with replication at all -- it was garden-variety Access
> corruption.
>
> >> > 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?? . . .
>
> No, but it can be a software problem -- something installed on the
> machine could be causing the file system to be unreliable. The most
> common culprit for this is Symantec/Norton AV software.

On one of the other laptops on this network their network consultant found
what he described as a corrupt Norton AV file. I'm not sure if they are
still using NAV but can find out.
>
> > . . . 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.
>
> Well, the problem is *corruption*, not replication, as is proven by
> the fact that the db corrupted during a time when the user was *not*
> synchronizing. '
>
> What version of Access is this? If it's A2K, then it could be that
> you're using one of the bad versions of Access, which is Access
> before SR1, and Jet before service pack 6. Anything before that is
> dangerous to use, and I won't let any of my clients use those
> versions at all.

It is Access 2000 SP3 with the latest Jet service packs (8.0 I believe)
>
> []
>
> >> > 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.
>
> It could be anything. I once had a situation where a replica stored
> in a server started losing replicability on a regular basis, and it
> turned out that it was caused by the application of an Exchange
> Server hotfix to that server. Fortunately, Exchange wasn't in use at
> all on that server, so once we discovered the cause, we were able to
> back out the hotfix and the problem went away (we then had a serious
> conversation with the IT consultants who'd applied an Exchange
> Server hotfix without asking us if we were even *using* Exchange
> Server!).
>
> AV software is the most common cause of problems with MDB files. It
> is basically useless for MDBs, as there has been no explit that
> infects existing MDB files (though there's a recent report of a
> Trojan embedded in an MDB that infects your machine; but that's
> delivered via email, so email scanning of MDBs can be enabled, while
> always-on MDB scanning can be turned off).
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc
>

Thanks again for your advice so far!

Regards

Ondine.
.

Quantcast