We're working on an AREV 3.12 application with one table that is having indexing problems. A user noticed that they weren't getting all of the rows in a report that they should. We've looked at it and doing everything we can think of and no joy. I'm hoping someone can point me in the right direction.

We have a table called WO_MSTR. The column that we've noticed the indexing problem on is called EQP_LVL1. The column is defined as a data column, single, left justified and a default display of 10 characters. I've checked and there is no data in that column over 7 characters in length.

I've removed all indexes from the table (from TCL, F10, DB Admin, Indexes, Update, Remove all indexing from a table), made sure that the !WO_MSTR was gone. Made sure that SI.MFS had been removed from the REVMEDIA row for WO_MSTR. In DICT.WO_MSTR deleted %FIELDS% and %PROTECT.SPEC% and had the system rebuild those. In the dictionary column for EQP_LVL1 there was a strange Data Type, so I removed that.

After all the indexing was removed, I ran a LIST statement (LIST WO_MSTR EQP_LVL1 BY EQP_LVL1 BY @ID WITH EQP_LVL1 ] 'MV'). The EQP_LVL1 is made up of 2 apha characters and 5 numeric characters. I choose 'MV' because we have a list of keys and their EQP_LVL1 values and in checking my LIST results against the list, this is where things seem to start to go wrong (at least in a ordered list). My LIST statement on an unindexed table gave me the right results.

I then indexed just the EQP_LVL1 column and reran the LIST statement. I got 5 less rows. I checked the rows (at the raw data level) that were not on my indexed list and I couldn't see any problems. No extra spaces, value or subvalue marks or anything else.

I've run out of ideas. Any suggestions would be a big help.

Thanks,

Michael Slack

Are you sure there are no @Vms in keys?

The Sprezzatura Group

World leaders in all things RevSoft

in addition to Sprezzaturas suggestion .. check all the data for ANYTHING non-alpha (standard 0-9, a-Z and *)

I know how odd things can happen to that data

Thanks for both of your's help. It turned out to be two keys with an @VM in them. I wrote a little program to find any keys with bad characters, copy the rows and give them new keys and delete the originals. Then rebuild indexes and we were in business. Again, thanks for your help. I might have been pounding my head against a wall for a good while before I found the problem if I hadn't had your help.

Thanks,

Michael Slack

now you have a good tool to add to your arsenal. anytime indexes act up .. run it

Glad i could partially help say hi to the gang for me

View this thread on the forum...