Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 10 DEC 2008 10:39:04PM Bob Silverstein wrote:

I know that this might not really belong here but I figure more people will see it.

I run OI8 while using Arev to maintain the files. I have a corrupt bang file and get this (borrowed) message.

Fatal Error Readnexting in table LOAN_TEMP

Group Format Error:

OS File : LOAN\DATA\REV66215.OV

Group # : 00000039

Wrong Overflow frame linked to group

ESC to terminate, Break to debugger? (ESC/

Dump freezes when trying to fix the frame.

I seem to get a lot of these.

Any ideas other than removing and rebuilding the indices?


At 11 DEC 2008 03:10AM [email protected] wrote:

Strong likelihood is you don't have write behind caching disabled on all workstations.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft


At 11 DEC 2008 08:56AM John Bouley wrote:

Another possibility is either AREV or OI is accessing the files locally (not through the service). I had a similar problem with SYSLists in OI. Turns out OI's revparam was in a parent folder and some users did not have network rights to it. The result, some users using the network service and others not. It only corrupted when the "local" users were doing rlist/sorts.

HTH,

John


At 11 DEC 2008 12:21PM Richard Hunt wrote:

The short answer… no.

The primary frames that overflow have pointers that identify the overflow frames. These pointers are a series of pointers that point to the overflow frames in sequential order.

I believe that the overflow frames keep track of the primary frame it belongs to. So if the primary frame points to an overflow frame and that overflow frame believes it does not belong to that primary frame, you get the "wrong overflow frame" error.

I really do not know how to "hard" fix this since the overflow frame now believes it belongs to another primary frame. Given that I do not think you can determine the correct overflow frame that now belongs to the primary frame or even if the overflow frame exists.

There is way too much consideration to be able to program something to untangle the primary and overflow frame pointer mess. Rebuild the index, restore the data file from backup or truncate the frame with the wrong overflow frame pointer. Note that truncating will still leave your index corrupted.

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/b480a40e59a2ab288525751c00140eb1.txt
  • Last modified: 2023/12/28 07:39
  • by 127.0.0.1