I have a table in ARev 3.12 that has a GFE that we seem to be unable to get rid of. We have fixed all the records in the group with the error except for one. The following error comes up when we attempt to edit the record:

Fatal Error Reading 1754284 in table STATUS

FS126

Group Format Error

OS File: FILES\REV25047.OV

Group #: 00030350

Wrong overflow frame linked to group.

We ran a VERIFYLH on that table and on that specific group it showed the following description:

Code: 9

"Group 2733 in overflow frame header (frame 970624) is not consistent with the current group"

The VERIFYLH report also showed about a dozen other groups that it believed to have GFE's in them as well, but after doing a DUMP on that table, it only showed that group 30350 had an actual GFE. What we also found that was odd is that during the DUMP on 30350, we attempted to Ctrl+F and it appeared to do nothing. Furthermore, while using the right arrow key to move through the group, the group number would change from 30350 to 2734 as soon as we would get near the end of group 30350.

Any help in fixing this would be appreciated.

[email protected]

SRP Computer Solutions

Frank, as an observation, the group numbers seem very very high. Backup first, then can you Ctrl-E to hex edit them and change their values to smaller numbers. The error will change but the Ctrl-F fix may then behave OK.

Is the error 'recurrent' or is it just 'persistent' on this one occasion?

Steve

I had the same problem, in my case, it was by mistake in the hardware, concretely in hard disk. The way like I solved it it was renaming the file from operating system, copy as original, later I ran Dump, Ctrl-E and change the group number, write down the keys involved in the group, fixing later on.

Thanks for the suggestions and that was probably the route I was going to have to take, but I was hoping for a way without having to copy all the records. There are about 1.3 million records with over a gig in data. The client's server (where ARev resides) is up five days a week from almost 7am to 7pm. This makes copying the data almost an exercise in timing. If anyone has any other ideas other than the ones suggested, I would appreciate it.

Also, to explain what I meant by reoccuring - what I meant was that no matter how many times we Ctrl+F it, it never seems to go away.

[email protected]

SRP Computer Solutions

I get this GFE all the time and Cntrl-F never seems to work. It seems that the forward frame is mislabeled and it goes forward to a completely different group. Of course, Cntrl-F never works for me–no matter what the GFE is. Rather than copy out the entire file, I use a log file to find only the records for this file with key numbers higher than #### (going back to last clean backup), then copy them to a temp file. Restore the files (data and index) and copy back the last few days of records. Then update the indexes. If the GFE is in a group with one of these records that I'm attempting to copy, then it's lost but usually we luck out and manage to save everything. —-FRAN

If you have that much data it would be worth writing a MFS to double/triple-write the data to additional copies of the big file. Then salvage is just a DOS copy away. Disk is cheap.

Steve

Hi,

Are you using the NLM? If so, there are "phantom goofies" that can occure. It is caused by very large files with gross overflows and workstation i/o contention that confuses the NLM file server. I found the only way to fix this is to reboot the server and resize the files to minimize overflow. Or use an MFS to break a large file into several smaller files.

View this thread on the forum...