We have a client running Arev 2.12 app with Novell 4.x and Win 95 clients. One of our data files experienced a GFE. When we dumped the file, we were never asked for a re-compress. Upon listing the file, no records were present, yet the fisical file remained the "proper" size and a list of the volume indicated the appropriate foreign name.

Any thought as to why this could occur. We had to revert to a previous version of the file to resume operations.

Bill

What exactly did you do in dump? Is any information visible in DUMP? If not in the first frame, how about if you scroll down? It is possible that you have a black %RECORDS% record on file. If so, remove any quickdex/rightdex, and if %RECORDS% remains delete it. Then you should see all your records. If the file is small enough, you can reset up your quickdex if needed.

I was attempting to dump a file of approx 31,000 records with a record size of 166 fields. The physical file is nearly 19 megs between the lk and ov files. The default value of 31,nnn remained within the file. Thus, I believe the %records% was current.

Also, when we attempted to lh_verify the file before the dump, the process did not come to a normal end with a GFE report. It was only via GFE error message that we knew of the data corruption.

This file is too big for a quickdex. If you have one, it must be removed. Do that by typeing DICT filename, press F6 and follow instructions.

First, %record% is not limited to any set number of IDs, it is limited to 64K, so unless your keys were 2 bytes or less, you blew %records% out.

Secondly, under some circumstances I have yet to discern, though it has happened to me, the records are not copied back and the temporary file is cleared. RTI and I went around about this several years ago; they must be busy.

Larry Wilson

View this thread on the forum...