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 15 MAR 1999 07:50:33PM F.H. SMITH wrote:

I HAVE FILES WITH MULTIPLE BTREE INDICES.

SOMETIMES A RECORD WILL BE ADDED AND ONLY SOME OF THE

INDICES WILL UPDATE. IF I FORCE A RE-BUILD OF THE INDEX

THAT IS MISSING IT WILL APPEAR.

AREV: 2.12

NETWORK: NOVELL 3.12

INDEXING DONE ON INDEX SERVER.

AREV NLM IN PLACE.

THANKS FOR ANY HELP

FRANK SMITH


At 16 MAR 1999 03:32PM Warren wrote:

Do the indexes every get added without a forced rebuild?

What are your indexing parameters set to? e.g. Update on query?

Are you using a dedicated indexer or indexing at the workstations?

Often on a high transaction system users will get the message something to the effect that an 'index is being updated' and allows them to but warns their update will be lost. Are you sure the users are letting index updates to complete?


At 17 MAR 1999 02:39PM F.H. SMITH wrote:

WE USE A MACHINE JUST FOR INDEXING.

MUSH OF THE TIME ALL INDICES UPDATE JUST FINE BUT LATELY

WE HAVE ENCOUNTERED THE PROBLEM OF SOME NOT INDEXING MORE

AND MORE.

FRAN SMITH


At 17 MAR 1999 03:35PM Warren wrote:

Is the problem isolated to one data file or does it happen to more than one file?

If it is isolated to one file, kick the users off the system and make sure they stay off, remove the indexes on that file and add them back again. One of the control records might be corrupt or an orphaned index record may be in the !file.

Usually the best way to fix this is to record all the index setting for the file, clear the !file associated with the file (e.g. Filename=INVOICES, clearfile !INVOICES), then go into the indexing menu and remove all indexes for that file (this clears out the indexing stuff in the dictionary). Then add the indexes back.

If you're having the problem on more than one file it could be any number of things from a flaky network card, bad cable to a file sizelock setting.


At 17 MAR 1999 09:34PM Warren wrote:

Further thoughts:

Check the sizelock parameters on both the data and !files of the culprits:

With no one else on the in ARev From TCL type:

DUMP filename

In the upper right area there will be a parameter SIZELOCK=x

If it is not 0 (zero) set it to zero by pressing the minus (-) key on the keypad.

If SIZELOCK is set greater than 0 then the file will not resize automatically. If the modulo is too low for the number of items, overflow frames have to be added. Overflow frames will slow down file reads and writes which could be causing frustrated users to press the escape key during index updates or shut down ARev on their workstations.


At 19 MAR 1999 02:12PM F.H. SMITH wrote:

WHEN I RESET THE SIZELOCK(FROM 2 TO 0) ON THE OFFENDING FILES,

IT LATER RESET TO 1. I BELIVE THAT THE ONLY PERSON AT THIS SITE

THAT KNOWS HOW TO GET AT THIS DATA IS MYSELF. IS THERE ANY WAY THAT

THE SYSTEM IS RESETING THIS SIZELOCK?

FRANK SMITH


At 19 MAR 1999 03:52PM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:

Certain instances in RTP11 and RTP12 (ReadNext and Select) will update the current sizelock by 2 to prevent resizing during reduction. However, no Revelation Technologies supplied process will increment a sizelock by 1.

akaplan@sprezzatura.com

Sprezzatura Group

www.sprezzatura.com_zz.jpg


At 19 MAR 1999 06:37PM Warren wrote:

I thought when you create file it initially has a sizelock of 1 until a select is done on it, that thought being that if you're going to initially populate the file you don't want it resizing to save time (especially on an import).


At 19 MAR 1999 07:11PM Warren wrote:

No one else is in ARev when you reset the sizelocks with DUMP, correct?

If you're finding sizelocks GT 1 with no one else in ARev even after you've reset them previously it is a good indication that users are exiting ARev abnormally, i.e. closing the DOS session, rebooting or shutting of the system without logging out of ARev normally, pressing ctl break and typing OFF. Maybe there is a hardware problem on one of the workstations causes them to reboot it often.

Further thoughts: Are you running nightly backups? Is the backup complete by the time users are on the system? Has there been a change to the backup process or network around the same time the problems began?


At 20 MAR 1999 08:15AM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:

Yes, that's true, but that's a little different than manually setting it to 0 and having the file jump back to 1 all by itself.

akaplan@sprezzatura.com

Sprezzatura Group

www.sprezzatura.com_zz.jpg


At 21 MAR 1999 03:30PM F.H. SMITH wrote:

THE CHANGE TO SIZELOCK 0 WAS DONE WITH NO ONE ON THE SYSTEM

(I'M DOING IT AGAIN AT 11:30 SUNDAY WITH NO ONE IN THE BUILDING OR DIALED IN. I'L SEE IF IT STAYS PUT).

YES WE DO A NIGHTLY BACKUP, BUT NO ONE IS ALLOWED TO LOGIN UNTIL THE BACKUP IS COMPLETE9THEY ARE LOGGED OUT BEFORE THE BACKUP STARTS).

MANY USERS LEAVE THEIR MACHINES ON AND LOGGED IN, THE BACKUP LOGS THEM OUT. THERE SHOULD BE NO FILE UPDATE ACTIVITY AT THE TIME OF FORCED LOGOUT. I WILL SEND EVERYONE AN EMAIL TELLING THEM TO LOGOUT, BUT I HAVE LITTLE HOPE THEY'LL LISTEN. IS THERE ANY OTHER WAY TO BRING THEM IN FOR A SOFT LANDING?

THANKS FOR ALL THE HELP (ALSO TO AARON KAPLAN)

FRANK SMITH


At 23 MAR 1999 09:44AM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:

Replace index process, if it's past 11pm or something, perform off.

akaplan@sprezzatura.com

Sprezzatura Group

www.sprezzatura.com_zz.jpg


At 23 MAR 1999 05:35PM Warren wrote:

Right, what Aaron is getting at is if the background indexer is still active during the backup, to open files may be causing problems.

You can add a post indexing process that checks the time and logs out the indexing station. Search the message base on words such as backup, waituntil, waituntl because we discussed this before and there should be some coding examples on how to do this.


At 24 MAR 1999 09:51AM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:

Thanks Warren, I was being a bit, uhhmmm, curt, no offence, Mr. Baker.

akaplan@sprezzatura.com

Sprezzatura Group

www.sprezzatura.com_zz.jpg

View this thread on the forum...

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