Weird behavior after index rebuild

[Boaz Bezborodko]

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