run index maintenance error

[Richard Kreiss]

> > Jeff,
> > 
> > In answer to your question:
> > 	1. I have tokenized the processing table as I placed 
> msgbox to show 
> > where the process was when the error occurred when using rreport
> > 	2. The index has been built, rebuilt, deleted and rebuilt
> > 
> > Here is the message
> > 
> > 
> > 
> > *** A filePro Error Has Occurred ***
> > 
> > Fatal error
> > 
> > On File: W:\ccp/filepro/l_card/index.C
> > 
> > Invalid index.
> > Run Index Maintenance to rebuild the index.
> > 
> > 
> > So, with the processing table and token table the same, why should 
> > dreport work and rreport fail?
> > 
> > Richard Kreiss
> > GCC Consulting
> > 
> 
> Have you re-tokenized the OTHER processing tables involved?  
> What version of dreport, rreport and dxmaint are you using?  
> You should supply 3 different version numbers - get them by 
> running each program with PFVER=ON
>  
> What is the exact command line that you are using when you 
> use dreport?  What is the exact command line that you are 
> using when you use rreport?
> 
> Do you know that this lookup is the cause of the error?  Do 
> you have a show statement immediately after this line that 
> never gets executed?
> 
> Granted that this should not cause an error, but what
> key(s) and length(s) is the index built on?  Are they the 
> same as the key to your lookup?
> 

Windows version 5.6.06 D9 and R9

Yes, both have been retokenized.

I use the same command line for both, just change r to d.

Menu command line

/fp/rreport l_card -f expire -v sel_expire -ic -a -u -pq

Yes I know that the  lookup is causing the error.  Placed a msgbox just
before the first - lookup and when the process hit that line, the index
error message appeared.

There is no show statement after that line, however I did test with another
msgbox to indicate if the process was crashing when the last record was
selected.  Never reached that point.  Always on the first - lookup line.

I have checked the data to see if there was anything odd, but there isn't.

Richard

Since this is a - lookup and all of the year fields are just (4,.0) fields,
there should be no problem with that.