I have currently stepped into some ARev support work where the application has some serious problems. One of the current problems is a "phantom index" located on a table. When doing a LISTINDEX, the output shows that the table in question is related to another table called COMMONX. COMMONX does not exist as a table in the application nor is it related to any column in the table it is related to.

Any help in removing this index would be appreciated.

[email protected]

SRP Computer Solutions

Some suggestions:

1. Create the bogus table temporarily with just the field that is relationally indexed. Go into the Indexing/Relational Menu and get the item that is bogusly indexed. Change the Yes to a No which hopefully will remove the dictionary control.

2. Create the bogus table with the dict item and manually edit the dictionary to put the index information where it belongs. Then try to remove the index.

3. Edit the dictionary and manually remove the indexing for the affected field. You may also have to diddle the media map.

Don Miller

C3 Inc.

Indexing information is stored in several places in Arev. I believe LISTINDEX does not look at the !file but at the dictionary itself. Use the system editor to look at the dictionary record. Is there relational information in field 23? Look in the field that is related to and see if there is anything in field 24. The easiest thing to do might be to simply delete everything past field 11 in the dictionary record and save.

The solutions suggested would probably work, however there is no field set to be related to that table (COMMONX). Therefore, editting the dictionary items to delete the index information will not work. You also cannot recreate the table for the same reason - there are no fields set to have a relational index.

Any more ideas?

[email protected]

SRP Computer Solutions

I was suggesting editing the related FROM dictionary record.

The two tables in question are DEAD.ORDERS and COMMONX:

COMMONX does not exist anywhere and therefore, has no dictionary items to edit.

DEAD.ORDERS has 158 dictionary items, none of which have anything in field 23 (except for %RECORDS% and %PROTECT.SPEC%).

Am I misunderstanding which items needs to be edit?

Thanks for the continued assistance…

What gets listed for DEAD.ORDERS and COMMONX when you do each of the following queries:

LISTINDEX

LISTINDEX DEAD.ORDERS

LISTINDEX COMMONX

Judging from what you have written thus far, I would guess you get a listing for a relational index when you type LISTINDEX DEAD.ORDERS. I notice your file name has a period in it. What version are you using? I think the dictionary layout changed, and I may have pointed you to a field that was relocated after your version. I'll have to dust off some documentation to find out. Anyway, what I would do is edit any fields that show up in the above listings and be sure all indexing information is cleared out.

Do you use setattach images perchance? It may be a good idea to refresh your image.

In LISTINDEX, it shows that DEAD.ORDERS has a relational index with the table COMMONX. This is the only list that actually shows COMMONX as being related to DEAD.ORDERS.

In LISTINDEX DEAD.ORDERS, it shows no column with a relational index on COMMONX. In fact, there is not supposed to be any relational index on DEAD.ORDERS.

LISTINDEX COMMONX brings up "The COMMONX table was not found."

In this particualar version of Arev, the period is not a problem.

So far, all the documentation that I have read points to field 23 being where relational index information is stored. I checked another table which does have a relational index and field 23 is where the info is stored.

As for clearing the indexes: there are 18 columns with either a btree or Xref index on them, and we are dealing with a couple hundred thousand records in this table. Although it could be done (clearing the indexes), it is really not the option I want to pursue if at all possible.

I have not used SET_ATTACH_IMAGE so that might be something I can try.

Thanks again.

[email protected]

SRP Computer Solutions

Frank,

Victor was suggesting that maybe this version of AREV has been upgraded from an older version that stored relational index information in a different position. This might explain why you can't locate anything in field 23 since it's actually somewhere else. Given that your application is almost 10 years old I'm sure it's gone through several AREV version. Look at the WHO and see what the upgrade path has been for this.

Also, Victor was not suggesting you use SET_ATTACH_IMAGE, but rather if you were using it then you might want to refresh it since it may be attempting to reference a missing table (i.e. COMMONX.) In any case, I don't believe this AREV system is using this but I could be wrong. Something you may want to look in to.

[email protected]

SRP Computer Solutions

I ended up just wiping all indexes from the DEAD.ORDERS file and rebuilding it from scratch.

Thanks for your help.

Frank Tomeo

View this thread on the forum...