An index problem. (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]]


==== An index problem. (AREV Specific) ====
=== At 25 AUG 2006 12:02:06PM Michael Slack wrote: ===
 
{{tag>"AREV Specific"}}
 
<QUOTE>
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
</QUOTE>
----

=== At 25 AUG 2006 12:26PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:  ===

<QUOTE>Are you sure there are no @Vms in keys?



[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 26 AUG 2006 10:59AM dsig@sigafoos.org wrote:  ===

<QUOTE>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 

</QUOTE>

----

=== At 28 AUG 2006 06:47PM Michael Slack wrote:  ===

<QUOTE>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

</QUOTE>

----

=== At 29 AUG 2006 12:01AM dsig@sigafoos.org wrote:  ===

<QUOTE>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

</QUOTE>


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