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?

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?

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

The Sprezzatura Group

World Leaders in all things RevSoft

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.

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

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

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.

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

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…

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.

One more thought:

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

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

View this thread on the forum...