GFE (OpenInsight 64-bit)
At 09 NOV 2021 04:02:37PM Jim Vaughan wrote:
I have a file that has a GFE, the detail says:
Group 45056 in overflow frame header (Frame 1024) is not consistent with the current group.
Rev file is a local file and is not being accessed over a LAN.
What might cause this?
Jim R Vaughan
At 10 NOV 2021 08:52AM bshumsky wrote:
I have a file that has a GFE, the detail says:
Group 45056 in overflow frame header (Frame 1024) is not consistent with the current group.
Rev file is a local file and is not being accessed over a LAN.
What might cause this?
Jim R Vaughan
Hi, Jim. You have this under the OI 64-bit category, so it's an OI 10.x? Running UD 5.x?
Are you saying there's only one user on this system? No engine server running, no internet access, etc?
Thanks,
- Bryan Shumsky
At 10 NOV 2021 12:03PM Jim Vaughan wrote:
OI 9.4
All networks 2.1, file is local to his system, held on C: drive.
Only one user, accessing the file that has the GFE.
Jim R Vaughan
At 10 NOV 2021 12:14PM Andrew McAuley wrote:
You are accessing a type three file with a type two driver.
The type two driver will not recognise the modified header formats so will report a GFE.
World leaders in all things RevSoft
At 10 NOV 2021 02:58PM Jim Vaughan wrote:
No other tables that are attached from the same directory report a GFE.
We noticed the problem because writes to this and only this table would fail.
Jim R Vaughan
At 10 NOV 2021 03:22PM Andrew McAuley wrote:
Can you screenshot the LH_Info window?
World leaders in all things RevSoft
At 10 NOV 2021 03:59PM Jim Vaughan wrote:
Post removed by author
At 10 NOV 2021 04:01PM Jim Vaughan wrote:
Jim R Vaughan
At 11 NOV 2021 06:35AM Andrew McAuley wrote:
Yup that's a type 2 - sorry I saw that you had posted in the OI10 section and knew that OI10 ships with type 3 files so jumped hastily to a conclusion :).
Stating the obvious, the pointer is way out of line with the reality of the file, so looks like you do have a GFE. How it happened? Tough to say without looking at the file itself. It's a very small file so would be relatively easy to take to bits programmatically or you could use DUMP in AREV32 to look at it…
World leaders in all things RevSoft
At 11 NOV 2021 01:12PM Jim Vaughan wrote:
I can fix the file by replacing it with an empty version and repopulating the data.
What I am more concerned about is not having it happen again. Would using Dump allow me to determine the cause?
Jim R Vaughan
At 12 NOV 2021 03:10AM Andrew McAuley wrote:
That depends ;). For example back in Rev D days, dump showed that the file was being overwritten by print output because DOS had run out of file handles so just reused one - fixed by increasing files/buffers in config.sys :).
It would show WHAT was in the frame under question which MAY give a clue as to what has happened. This is, regretfully, detective work, and there's no easy answer most of the time.
World leaders in all things RevSoft
At 12 NOV 2021 12:49PM Jim Vaughan wrote:
Ok, I will take a look.
Thanks for the help.
Jim R Vaughan