[[https://www.revelation.com/|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]]
==== INDEXING PROBLEMS WITH AREV 3.1 & WIN. NT (AREV Specific) ====
=== At 08 JUN 1998 05:20:47AM MIKE EDE wrote: ===
{{tag>"AREV Specific"}}
We are experiencing problems with indexing (BTREE) with
Arev 3.1 and Windows NT 4.x. The first user searching the Btree index finds matches OK. If, however, there are more than one user attempting to search, then matches are not found. Are there any sharing issues (using Microsoft LAN Manager driver)
----
=== At 08 JUN 1998 07:18AM Mike Ruane, WinWin Solutions Inc. wrote: ===
Mike-
Is NT the network, or the workstation, or both?
If it's the network, you should probably get the Linear Hash NT service from Revelation software. It's made specifically to make Arev work on these networks that weren't even invented when Arev started.
Hope it helps-
Mike Ruane
WinWin Solutions Inc.
WWW.WinWinSol.com
----
=== At 13 JUN 1998 05:14PM Larry Wilson wrote: ===
Try the MSDOS 3.1+ locking; it seems to work better. BTW, you don't have that anchor of an NPP on the system, do you?
Also, as APK pointed out in a message up the page, indexing was not really close until 3.12, especially if you have a file with 4+ key parts and 50K+ records.
----
=== At 14 JUN 1998 08:54AM Aaron Kaplan wrote: ===
I don't mind you harping on this, since it's a serious issue and affects all out of the box versions of the software from 1.15 through 3.111. However, you do seem to go to scare tactics sometimes (my impression, knowing the details better) and I'd really like to set the record fully straight. This way you can inform people of the real problems and not have people chase problems when this doesn't affect them.
In version 1.15 of Advanced Revelation, the Linear Hash filing system was ported from ASM to C. In this port, a very obscure error was introduced. When dealing with large files with large keys under low memory conditions, the pointer to the next group in the readnext logic would sometimes get corrupted.
Readnext deals with chuncks of record keys in groups. The system holds a pointer to the current group number. All keys from this group are read into a buffer. The READNEXT code returns one key at a time from this buffer. When the list is exhausted, it goes to the group stack pointer, gets the next group, populates the key list, and the process continues. If you are doing a scrolling list, you can see the effects of this. Periodicly, there is a slight pause, and maybe disk access. This is when the system is pulling new keys. If you are using OpenInsight, if you trace through the debugger (and are working with reduce/selects), you can watch all of this in @CURSORS.
The bug in question here affects the pointer to the next group. This value would become corrupted. Most of the time, this corruption resulted in a lower number value. Very, very rarely the pointer will jump to a higher number. When the pointer is lowered, groups that had already been processed will be processed again. When raised, groups will be skipped. How this manifested itself in various applications is impossible for me to know. However, I can tell you that if you see the status bar indicated a percentage of over 100%, then you have been affected.
It's important to note a few things. One is that this is random. Just because it happened once, does not mean it will happen in a second pass.
The second is that indexing is only affected if the pointer increases. A decrease in the pointer will only cause the rebuild to take longer to execute since each index value will only be placed once in the list. You also have to do a rebuild to have the problem even begin to become an issue. The logic that has the error is not invoked during routine index updates nor is it invoked during index retrieval. Readnexting is not called since the index nodes are travesered. The keys are known and there is no reason to ever go through index file groups sequentially.
It is also important to note that all three criteria must be in place. It must be a large file (modulo of a couple thousand or so), the keys must be very large (4 or 5 parts but an average length of about 20 or so) and memory conditions must be very low. If you take a file, 13 million records, average key length of 50 chars and start running selects from TCL level 1 with typical and recommened memory configurations, you will never see the problem. This is part of what took Revelation so long to finally duplicate the problem. Running this exact test (I should know, I performed it) the problem never manifested itself, even using clients actual data. It wasn't until we loaded up a few TCL levels and really bogged down memory were we able to reproduce the problem. The tighter the memory, the better the chance of it seeing. Even running on TCL-9, we still only received the problem about once in every fifteen runs.
Now, the good news about all this is that 3.12 fixes this striaght out of the box. The other good news is that OpenInsight never had the problem. Even more good news is that the NLM, NT Service and NPP never had the problem either. With more and more users moving to these network drivers, the possibilities of this affecting you are moving even more remote.
I hope this finally sets the record straight on this issue once and for all.
akaplan@sprezzatura.com
[url=http://www.sprezzatura.com]Sprezzatura, Inc.[/url]
[img]http://www.sprezzatura.com/zz.jpg[/img]
----
=== At 14 JUN 1998 06:49PM Victor Engel wrote: ===
I wonder if WS_FTP has the same problem. I get over 100% sometimes with it .
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=E9B0A8B8BFD5A8FA8525661D003357AF|View this thread on the forum...]]