Have a table with 25 million+ records and appears to have a GFE.

This is a comment table. Date, time, who, comment and source.

FS1003 is the error. Looks like group 249305 as reported from @FILE_ERROR. Found the error from a loop…readnext…repeat.

ReadNext Status() error equals 2.

Have been using the UD 3.0 for 4 yrs. there, OI version 7.0.1

Table is still being written into constantly.

Looking for suggestions on fixing this table without losing data or at the least very minimal loss.

Thanks.

Bruce, the solution I have to this, if the item ids are indexed, is to copy them out into another file, clear the original, and copy back.

Not much use with 25m records though.

This approach works for me as even though a GFE exists, using a hashed read from the known key will get every record except those within the frame containing the GFE, and even some within the frame.

Using a select/readnext will not give the same results.

Seeing as there are so many items, and the file is live this approach may not be suitable.

If you could find all the item ids in the corrupt frame, and delete these, you might be able to have a clear frame, and then it might clear the GFE and then be OK writing them back (no justification or reasoning for this, just a hunch). Dont know how you can determine this.

In the old Pick days we used a command from TCL to look using a hex editor.

You probably want to set Sizelock to 2 if doing this to avoid any changes to the modulo.

I presume you have tried fixing the GFE first.

Also, make a copy of the database, and use this to try out your solutions before doing so on the live.

Colin

Colin,

Thanks for the reply. In my old General Automation Pick days we used the system debugger to fix them, I learned a lot that way.

The file is not indexed. I removed the indexes a while ago. I'm not a huge fan esp. with large files and a lot of users in a PC/Server environment. Lots of lock ups etc.

What I did was to create a CLIENT_DETAIL table where the id was the same as the CLIENT table and in Attribute is a sequential counter of the last Comment for that Client. The CLIENT_COMMENTS key is CLIENT#*SEQ so I only need to read the detail and loop from 0 to the last seq# on the detail to get all the comments for a client.

Your suggestion is pretty much exactly what we were going to do; read each client, then read each comment and copy to another table. This omits the readnext. After each copy I will delete the record from the source and in theory should be left with just those in the frames that I can't get. Then I will resize it down and try to have it repaired with ARev (as per a previous posting I read where with the same type of issue). Honestly I'v never had luck fixing GFE's in OI.

Thanks, again and any info or suggestions are appreciated.

You could try setting @File.Error.Mode and deal with (ignore) the GFE yourself…

The Sprezzatura Group

World leaders in all things RevSoft

Yes thanks I looked into that, but neither your post or the documentation gives more detail as to what might be done.

"@FILE_ERROR_MODE is a boolean flag, indicating whether or not the system should deal with file errors. If true (1) the user program will handle the error. If False (1), OpenInsight will handle the error."

I'm not sure I understand how to use this in this case(my current comments table situation).

Well toggle it and select the file readnexting through. When you get the else on the read because of the GFE you can just ignore it and carry on to the good rows. With any luck you'll be able to record the Ids you were unable to salvage.

We've had some success with this in the past but YMMV.

The Sprezzatura Group

World leaders in all things RevSoft

Ok thanks, That's what I thought. I had already tried that but without success, was wondering if you were referring to something else. Thanks for the reply/suggestion.

I was wondering… what is the difference in file version 2 files (non universal driver) and file version 3 files (universal driver). The reason why I ask is because I do have a LH_SUB function that does extract alot of valuable information from the file version 2 files. I have not tested it on the file version 3 files.

The initial header byte is a different value reflecting the changed header size to accommodate the larger pointers.

The Sprezzatura Group

World leaders in all things RevSoft

View this thread on the Works forum...