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 27 AUG 1998 02:08:49PM Ed Arend wrote:

I am running the latest NLM for AREV on a Novell file server. I use a dedicated indexing machine to maintain the indexes.

I have one file that has 23 indexes defined. Recently this file became corrupt. I redefined the indexes. After doing so I ran verify and it tells me that my frame size is 256 and I need to run remaketable to change it to 1024. I also tried setting the load factor to 70% instead of the standard 80% to improve the performance of this index. It is the most heavily used file in my system.

I have run remaketable setting the frame size to 1024 but it makes no difference. When I run verify again it tells me the same thing. It is changing the file because it gets a new DOS name and the sizes of the .LK and .OV files change.

Any help is appreciated.

The current stats on the index file are below.

.LK size: 550,400

.OV size: 9,438,464

Frame size: 256

Modulo: 2150

Sizelock: 0

# of free frames: 7

Average # of rows per group: 4.85

Average row length: 879.16

Total rows in table: 10442

Load factors

.LK:.9881

.LK & .OV: .9735


At 27 AUG 1998 03:30PM Michael Slack wrote:

My guess is that you used a command like:

REMAKETABLE DATA table_name 1024

That would seem to explain why your DOS file names changed but nothing else. It would have taken the 1024 (in this example) as the estimated number of rows that the table will contain. You need the three other values that go before the new frame size because it looks at the postion of the numbers within the attributes, not the numbers themselves. So I would suggest trying something like this:

REMAKETABLE DATA table_name 10445 880 #_of_dict_real_data_entries 1024

The first three numbers don't have to be exact, because I'm from the West I tend to round-up. The frame size shouldn't be rounded, I use exactly what VERIFYLH gives me as a suggested frame size.

I hope this helps,

Mike Slack


At 27 AUG 1998 04:24PM Ed Arend wrote:

I have tried exactally what you suggest before. Each time I remade the table AREV ignored my specification of a 1024 frame size and created the 256 size instead. I will try again to see if perhaps I was making a typo or something.


At 28 AUG 1998 09:35AM Michael Slack wrote:

This is just a wild guess on my part but have you checked to make sure that the SIZELOCK for that tble is set to 0 (zero)? That might prevent it from resizing the frames (maybe).

Mike


At 28 AUG 1998 01:12PM Ed Arend wrote:

Oh it resized the frames alright…. it made them 256.

When I started all this Verify told me the frame size was 1024 but in the recommendations said to change the size to 1024 because the disk access was poor. When i followed the directions it made the frame size 256 despite the directive to make it 1024. Since 1024 was what I thought would be the default for any table this was baffling.

The verify program clearly shows that the size lock is set to zero. Unless this can not be believed then I would have to say that is not the problem.

Ed


At 01 SEP 1998 11:20PM Aaron Kaplan wrote:

I have no idea what would cause frame sizes to wig out. Best suggestion I have is brute force. Create a new file, copy in the records from the !file, then delete the !file at the OS level and rename the new 1024 frame file.

apk@sprezzatura.com

Sprezzatura, Inc.

www.sprezzatura.com_zz.jpg

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/3c3591d6fae663228525666d0063af87.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1