GFE's and Verify_LH (OpenInsight Specific)
At 24 SEP 2000 01:30:05AM Chris Callaghan wrote:
Hey all,
We've got a client who manage to find 2096 GFE's in a single index file using OI's Verify_LH, yet when using ARev's VerifyLH or Fixvol.exe we get nothing. They always appear in the same groups and you get the same result on different machines (whether over the network or local).
They aren't getting any FS errors when accessing the file and everything else seems to be behaving ok. I'm hesitant to get them to rebuild all the indexes for the file as it's pretty large (]40MB).
They've always been using the NLM and recently moved to the NT Service, so I'm at a loss to explain how so many could occur.
Could this just be a problem with OI's Verify_LH or is ARev and Fixvol just missing things?
At 26 SEP 2000 02:39PM Don Miller - C3 Inc. wrote:
Well..It seems to me that the NT service / NPP seem to generate "phantom GFE's" more frequently. I've moved several of my clients from NLM to NT without encountering troubles (mostly in AREV, however), which you say doesn't get any errors. Short of writing a piece of code to duplicate VERIFY_LH .. or whatever it's named in OI, I'm at a loss to understand it. Have you tried recreating the file in AREV, backing up the OI version, clearing it and then copying all the records from the original to the new and back from there to a cleared original? What was the error code found??
Don Miller
C3 Inc.
At 27 SEP 2000 12:50AM Chris Callaghan wrote:
Cheers Don,
Been playing around with the file in ARev, creating a new one, then copying all the rows in and still the same thing. ARev thinks its fine, but OI just doesn't like it. Even run fix_lh on all the groups, which seems to go ok (lots of rows copied etc..), but when you do the verify they are still there!
The GFE's appear in group 32770 and then in every group after that. The first 40 or so are type 7 (Row hashes to wrong group) and the rest are type 15 (??).
Any ideas?
At 27 SEP 2000 03:18AM [url=http://www.sprezzatura.com" onMouseOver=window.status=Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:
Have you run FIXVOL etc? Just seems suspiciously close to 32K….
World Leaders in all things RevSoft
At 27 SEP 2000 03:46AM Simon Wilmot wrote:
We have experienced problems when the file exceeds 32k.
Have you tried re-sizing the table to use a different frame size - 2048 instead of default 1024 ??
We have done this and even had to go to 4096 frame size. A large percentage of our clients have had to do this and it appears to be OK afterwards.
Simon Wilmot
Rebus Software (UK) Ltd
At 27 SEP 2000 05:40PM Chris Callaghan wrote:
Yep, ran FIXVOL - no luck unfortunately
At 28 SEP 2000 01:47AM Chris Callaghan wrote:
Thanks Simon, that did the trick!
Are there any problems having different frame sizes in different files? Should they all be the same or doesn't it matter?
At 28 SEP 2000 03:36AM Simon Wilmot wrote:
Chris,
No - no problems having a mixture (at least so far !!)
Simon
At 28 SEP 2000 02:23PM Don Miller - C3 Inc. wrote:
No problem mixing frame sizes. In AREV version 2.1x I think that the size of the frame buffer was set equal to a multiple of the largest frame size encountered, but I could be wrong. Sometimes I play with the Threshold value to cause more primary frames to be used (at the expense of re-sizing more frequently) if the file tends to go into overflow due to the way the hashing algorithm treats numeric key values.
Don Miller
C3 Inc.