Re: UNKNOWN REASON (-1017)

=?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.

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.

> 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.

> . . . 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.

[]

>> > 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
.

Loading