Index not updating (AREV Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[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]]


==== Index not updating (AREV Specific) ====
=== At 22 DEC 2003 06:26:02PM Ellen M Fox wrote: ===
 
{{tag>"AREV Specific"}}
 
<QUOTE>
My lab is running Arev 3.03 on Novell 4.11 using the NLM 1.5. There are actually 5 labs all run a dedicated index machine using the same program.  One of the labs has an index which refuses to update. Their are 52 tables with a variety of indexes and only 1 appears not to be updating. Does anyone have an idea of where to look or what to do?
</QUOTE>
----

=== At 22 DEC 2003 09:45PM ps wing wrote:  ===

<QUOTE>Our indexer checks the record in the indexing tables (the ones starting "!") with the id of "0" (zero). This holds the pending Btree updates (from line 2 onwards). Our indexer displays the table name so that we know whats its doing. Does your table have pending updates?



</QUOTE>

----

=== At 23 DEC 2003 02:44AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:  ===

<QUOTE>Hi Ellen! Is the one refusing to update a LARGE table?



[url=http://www.sprezzatura.com]The Sprezzatura Group[/url]

[i]World Leaders in all things RevSoft[/i]

[img]http://www.sprezzatura.com/zz.gif[/img]

</QUOTE>

----

=== At 23 DEC 2003 08:56AM Hippo wrote:  ===

<QUOTE>Just one thought:

 is the index based on table field?

... I 've seen the index on symbolic based only on foreign table. 

... there is nothing forcing index update when the field changes.

</QUOTE>

----

=== At 23 DEC 2003 10:06AM Dave Harmacek wrote:  ===

<QUOTE>Do all 5 labs share the same Indexer machine? or just the same Indexer setup on different machines?



and, are the 5 labs cloned off an original?



Dave

</QUOTE>

----

=== At 23 DEC 2003 02:24PM Ellen M Fox wrote:  ===

<QUOTE>Each lab has its own indexing machine.  The table is not large, our largest table Clients it appears to be updating just fine. 

</QUOTE>

----

=== At 23 DEC 2003 06:18PM Warren wrote:  ===

<QUOTE>Since it is not a large file probably the easiest thing to do is remove indexing from the file and add it back on again.

</QUOTE>

----

=== At 26 DEC 2003 05:09PM Ellen M Fox wrote:  ===

<QUOTE>Well I deleted and recreated the indexes.  I really hope that works

because it was very hard. The machine up and crocked on the

relational indexes.  But it is done and I will see if that fixes

the problem.

  Ellen

</QUOTE>

----

=== At 27 DEC 2003 09:01PM Warren wrote:  ===

<QUOTE>Ah, the old 64K limit "bug" on the relational index build.



I isolated this, at least on the data I was using. The problem appears to be that the index build builds a string of keys on a null "related to" field, even though it will not write out that record. In the case of the datafile, maybe only 1% of the records actually have a related to value in them and with enough records the 64K limit gets hit. Seems like a simple fix on Revelations part... "if len(related.value) then build..."



Thus if in File A, field "BKEY" relates to the record key for File B, the index builder with create a string of keys of File A even if "BKEY" is null. However, if the 64K limit is not hit, the indexing system will not write out a record in File B with key=".



Of course the 64K limit can be reached in other situations, but in my case there were never more than 20 related keys in any given record.



Work around? Complicated. You have to manually remove the indexing flags from the dictionaries and write a program to build the related keys field and other nonsense.



Seems like a simple fix on Revelations part...

</QUOTE>

----

=== At 28 DEC 2003 03:41PM Don Miller - C3 Inc. wrote:  ===

<QUOTE>Well .. I have never really cared for Rev's Relational Index anyway, so years ago, I rolled my own.  In your case, especially with a "sparse" universe, I would think it would be much safer for you to do the same thing.  It used to be the case that NULL keys were stored with a @VM anyway and could bump up against the 64K limit anyway. Unless you routinely use the Editor to write records (most key s are maintained from either forms or R/Basic Routines for most apps anyway), Relational Index really doesn't buy you very much.  The overhead in a rebuild is considerable.



Just my $.00002 worth.



Don M.

</QUOTE>

----

=== At 29 DEC 2003 02:41AM Hippo wrote:  ===

<QUOTE>One more thought:

 Wasn't the root index record of the field locked?

</QUOTE>

----

=== At 02 FEB 2004 05:04PM Larry Wilson wrote:  ===

<QUOTE>Could be a problem with the source file dictionary or with the indexing problem in pre-3.12 AREV.



Check my scan program on my website for a program that scans the dicts to make sure they are set up properly for indexing.



Larry Wilson

webmaster@AdvancedRevelation.com

972-768-2965

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=4DB8F4B57A8AA31485256E040080BA21|View this thread on the  forum...]]