Hi,

We have Arev 3.2 application and an index machine. We are having an error message 2,3 times a day, and it is so painful to rebuild each time. I am sure where to go to fix this problem.

Anyone can help me?

The error message is:

  The index row "E_CREF_XREF*2*" is missing.

     The indexed column "E_CREF_XREF"

        in the table "WORKSHEET"

           should be rebuilt.

Thank you.

Hannah

Blade Agency

email: hannah@bladeagency.com

You're better off REMOVING the index completely THEN readding and rebuilding.

amcauley@sprezzatura.com

Sprezzatura Group

World Leaders in all things RevSoft

I'll second that, having dealt with this beastie many times.

You may even have to clear the !datafilename before removing the indexing, but try removing it first. If the error message pops up while removing, abort, and CLEARFILE !datafilename. Make sure to document your index settings and make sure you clearfile on the !file, not the data or dictionary.

TB(#56) is very helpful in this.

It outlines exactly what steps to take to completely remove the indexes.

I would suggest dowloading the TB and fiddling around with it on a test system - some of the syntax changes from version to version.

James

Hi all,

I rebuilt the index for the table generating index missing messages.

I rebuilt all btree and the cross reference for 'E_CREF' column in 'Worksheet' table.

It was working fine for a while (exactly for a day).

And it did starting the same error message again.

So, what can I do now?

Could anybody help me? We need to run AREV nearly 24 hours.

It is so important for our business.

Thank you.

Hannah Choi

Blade Agency

You need to *remove* all the indexing from the file and then add indexing again. Be sure to document the index settings before removing them. If you get the error while removing the indexes, abort the remove, and clear the !filename, then remove indexing (actually this is usually faster than doing the normal remove procedure especially on very large files).

What happens is that there is an indexing btree record/node that points to a non-existing node or has no other nodes pointing to it. When you merely rebuild the indexes this 'orphan' node doesn't get deleted and eventually gets picked up again by the indexing process causing the error again and again.

You may have "garbage" in the file. We recently had index problems on a large file. Upon examining it, we noticed that @id and @Record were way out of whack on several dozen records.

First I removed all indexes.

Then, I created a symbolic field called ID_LENGTH, with the formula:

        @ans=Len(@Id)

As @id was not susposed to be longer than 12 digits, I did the following select:

  SELECT MEMBERS WITH ID_LENGTH GT 12

then, SAVELIST "whatever"

then, GETLIST "whatever"

Then a quick RList report before:

  GETLIST "whatever"

  DELETE MEMBERS

Then re-construct the indexes.

Hope this helps, Dean.

Hello,

Thank you very much for your response.

But we still have problems after rebuilding all the indexes. (removing and rebuilding). Even now, another btree column shows 'missing error' message as well. So it gets worse.

Any other way to configure this problem, please?

Thank you very much for your time.

Hannah Choi

Blade Agency

If this is the case, I would suspect either control characters in the record keys or the data column being btree indexed.

You probably need to write an RBasic program to check the keys or data columns for unacceptable characters.

Hi,

What keys or data would be the candidates for the inspection?

You mean I have to write a program to search the data fields of the column (Btree indexed) to see whether it has an invalid data values, right?

Please give me more hints before I start to write the code.

Thank you very much.

Hannah Choi,

Blade Agency

Check the keys in the problem file as well as the indexed fields/columns in that file.

You may have to remove the indexes before running the RBasic program if you do sort/selects on the file (triggering the error).

Also confirm that the dictionary definitions for the keys and indexed fields have the correct length and justification for the respective keys/fields.

View this thread on the forum...