Weird behavior after index rebuild

Richard Kreiss rkreiss at gccconsulting.net
Tue Jan 21 08:24:59 PST 2014



> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
> [mailto:filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com] On
> Behalf Of Boaz Bezborodko
> Sent: Tuesday, January 21, 2014 10:33 AM
> To: Filepro-List at Lists. Celestial. Com
> Subject: Re: Weird behavior after index rebuild
> 
> On 1/21/2014 9:46 AM, Boaz Bezborodko wrote:
> > On 1/21/2014 9:07 AM, Boaz Bezborodko wrote:
> >> Recently our server developed some corruptions on the drive because
> >> of unscheduled shutdowns (the UPS failed to keep the power up). After
> >> repairing the disks I decided to rebuild all the FP indexes since I
> >> found at least two that were somehow corrupted.  In one of the
> >> programs I found that it no longer performed like it used to after
> >> the rebuild. The program does a lookup to a file based on a date
> >> field.  The date field in the file is (8,mdy/) while the program was
> >> doing a lookup using a variable loaded with the data and had a edit
> >> of (10,mdyy/).  This used to work up until I rebuilt the indexes. As
> >> soon as I did this the lookup didn't find any records. Once I changed
> >> the variable to an edit of (8,mdy/) the lookup worked properly.
> >>
> >> I thought that FP handles all date values internally the same way.
> >> I'm sure that this particular index hadn't been touched since being
> >> upgraded from 4.8 and possibly before.  (We're now using 5.6.10R9 in
> >> Windows off a Samba file server.)
> >>
> >> One other point.  I found that one of the files had a problem that
> >> caused a "Sanity Check" error.  The file was one of the ones I found
> >> that had been corrupted which screwed up a process.  When I ran a
> >> program to correct the data I got this error on one of the records. I
> >> had rebuilt the indexes before running the program which cleared the
> >> data in some fields in certain records.  When I reran the process it
> >> started from the records that had not yet been touched. I forgot to
> >> get a screen shot.
> >>
> >> Is there a way to check the files for the kind of errors that would
> >> create a Sanity Check error?
> >>
> > It seems that I'm having other problems with date indexes.  I have
> > some old files that have a date field with a (9,mdy/)  I think the
> > original programmer did this so that the user would have to press
> > enter to move on to the next field.  The thing is that if I enter a
> > date (say 1/20/14 which I know is in one of the records) it won't come
> > up.
> >
> > In this case it's non-critical.  But there may be other areas he did
> > this that I haven't ID'ed.  Is there a way to fix this so that it
> > works the old way?
> 
> I just tried something else.  If I rebuilt that same index by going through the
> menu in DXMAINT and now I can pull up the record using 1/20/14.  But I'm
> still concerned about the behavior.  Do I have to do manual rebuilds of all
> indexes on date fields?
> 
> 
> 
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com

Ken will disagree with me on this issue.  I have found when I have had some index rebuild problems, deleting the index and then rebuilding it corrected the problem.

Ken has told me that rebuilding an index does delete the original index and then build a new one.  My experience has been deleting it and then adding it back takes care of  the problem.

The other issue may be a corrupt record(s) which can cause problems.

I would strongly suggest that the date field (9,mdy/) be changed to a proper date field size.  If you want to continue with requiring an <enter> after the date is entered, add @wlfxx: show"@" which will show a message "press <enter> to continue".  Same result and you have a proper date edit.


Richard Kreiss
GCC Consulting

Office: 410-653-2813






More information about the Filepro-list mailing list