Need a quick answer:

Problem: getting "Forward pointer in overflow frame points to a non existent position in the file" in 4 groups, tried to fix and it spawned 16, then fixed groups startgroup-endgroup and then it went down to 2 or three errors, tried again and it went back up. Cant do fix all groups cause it errors on variable exceeds max length. I got everyone out of the system and did a compress and re-verified and then I had no GFEs. Today I ran a check and I am getting 5 groups with the same errors. Is it possible that these are not real errors, maybe due to the OV size??? Please Help!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Table (17,997,824 LK size) (85,346,304 OV size) (17,576 MOD) (43,666 ROWS) (1024 FRAME) (80 THRESHOLD) (0 SIZELOCK) (216 DICTIONARY ITEMS)

I used the remake_table subroutine by CP ( on a local copy )and changed the frame size to 2048. It made the file larger and much slower even using the NPP and NT Service.

I plan to be working on new years day, so I can fix this problem. I thought possibly I could build a new table with the new attributes and copy all rows to new one and remap it back to the original table, indexing, etc. Would this fix the problem? what attributes would be good?

The table is still working, however, it freezes sometimes when accessing this table.

Please post all advise prior to 1/1/2000, cause I will be here attempting to fixing the problem.

OI 3.7 NPP NT Service 1.5 NT 4.0 Service Pack 6

Thanks

The OV file size wouldn't cause this error.

The forward pointer is the marker that tells the system what frame is next in the group. If this is pointing to a non-existant group, then that means there is a missing group in overflow.

The question then becomes how did it get there? A couple of things I can think of, in no real order.

One is that something is scrambling the frame when it is written back to the disk, so the forward is destroyed. If you have ARev, this is easy to see by looking at the value in dump.

Another reason would be caching, and this is the thing I'm thinking it could be. You're creating a new frame, but it's not getting written to disk right away, so someone else updates the header and the pointers all go astray.

Best solution I have is to turn off all caching, workstation, network driver, client drivers and see how that holds.

akaplan@sprezzatura.com

Sprezzatura Group

Bryce,

Assuming the possibility that it might not be a real-GFE, but rather a phantom, then I would do the following:

1. Make sure the GFE is evident on more than one workstation accessing the network. This will rule out RAM problems on the workstation.

2. Rename the files on the server and copy them to their original name in the same folder. This will keep data occupying the same area on the hard disk while re-locating the tables to another location. Repair and test the files as normal. If the GFE's stay away then you probably have a bad area on your server's hard disk.

3. Copy the application to a local hard disk, disconnect from the network, and test for GFE's. If there are any, repair and test the system again (you may want to use the application so the table gets used.) If the GFE's stay away then it is likely a problem with the RAM in your server.

4. If none of the above help then you probably have a real GFE and you need to apply Aaron's suggestions.

dbakke@srpcs.com

SRP Computer Solutions

View this thread on the Works forum...