Arev knowledgeable;

We've been cruising right along since moving our Arev 3.12 from Novell over to NT 4.0 (current sp, recent NT Service). Now all of a sudden some of our large processes are getting these fatal errors:

Fatal Error Reading 336981 in table 'TABLENAME'

FS107

Read Error

OS File=CLIODAT2REV49049.LK"

Esc to terminate, Break to debugger?

It appears to me that Arev is simply not able to read this file but why is something of a mystery. We are also getting intermittent 'slowness' on the network due to our nightly backups overflowing into the next workday.

So my question is: could this be a result of slow response due to the backups slowing down the server temporarily?

Has anyone else seen this type of problem and if so did you figure out what the cause was (and what was it)?

Any help is welcome - we're running Arev on a Compaq proliant 5500 with 640 Mg. RAM, NT 4 SP 6a, about 30 users with W95 and 5 developer machines using NT WS (also 4.0 SP 6).

Thanks in advance;

David Craig

ABC-CLIO

I realized I left out a couple of possibly relevant details:

The error has happened three times, each time on different tables.

VerifyLH shows no GFEs.

Searches appear to return valid results so the indexes appear fine.

After hitting escape, the process is rerun and runs to completion.

Thanks again;

David Craig

David,

My guess is that your backup process is locking these tables at the same point in time someone is trying to read a record. You need to be careful when allowing access to your AREV system while a backup is still occuring.

[email protected]

SRP Computer Solutions, Inc.

Thanks Donald,

It's looking more and more like that's the case, our problem is 'backup creep' in that it runs longer and longer and before you know it it's not finishing until the afternoon. Right now we're looking at the logs and tracking the errors to establish cause and effect and lobby for a change in the backup order - our data is relatively small (about 8 gigs) where the whole backup is rapidly approaching half a terabyte so it seems to me that the best solution would be to put our data first in the backup order so, as you say, we won't have users accessing the data while the tables are being backed up.

Do you know if there's risk of corruption in addition to the inconvenience of errors? We have gotten it several times from computers which were background indexing and that concerns me.

Thanks again;

David Craig

ABC-CLIO

David,

There is the potential that if a .OV file is locked by the system, then AREV might consider it to be missing. As a consequence, AREV will simply recreate one for you…empty. Hence, it is possible to lose data and get corruptions at the same time.

[email protected]

SRP Computer Solutions, Inc.

Just for a little historical context. Way back when DOS was the only viable option… copying REV files from one location to another was an obvious way to replicate applications. DOS used to very kindly say "Oh look a zero length file - I won't bother copying that" - so all the zero length OVs got omitted. So AREV 1 would attempt to open a file and fail as the OV file was missing.

Understandably people became a bit hacked off by this.

So (history tends to repeat itself) Revelation worked around a Microsoft problem and said "if the file isn't there we'll just recreate it with zero length to save the developer hassle".

Unfortunately the error message returned when a file is exclusively locked by backup software is the same to Revelation as "the file does not exist" so…

The Sprezzatura Group

World Leaders in all things RevSoft

Donald and Andrew;

Thank you both - especially for the information regarding losing data. Our data is our product so the possibility of losing it will get instant attention and action.

David Craig

ABC-CLIO

Andrew or Donald;

Do you know if this is also an issue with OI? I just realized we also have a small OI database that may have conflicts with the backup as well.

Thanks in advance;

David Craig

ABC-CLIO

Identical problem…

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...