Running a report without indexes

[Kenneth Brody]

On 3/19/2013 10:50 AM, Ian Wood wrote:
> Last night's error was on my A/P file, index.M, there's no consistency on
> which file or index it occurs on.  There are no lookups being performed, it
> is a straight export ascii dump of the data, it is the exact same code in
> at least 35 of the files.

Because you are running with "-ro" and not modifying anything, unless you 
are running the report off of index M, I can think of no reason why filePro 
would be accessing that index, aside from a lookup.

> When I went into my A/P file this morning, index.M does not say it's an
> invalid index, and accessing the file via that index appears to be all in
> order.

You may not have accessed the corrupted part of the index.

> On Tue, Mar 19, 2013 at 10:42 AM, Kenneth Brody <kenbrody at spamcop.net>wrote:
>
>> On 3/19/2013 9:55 AM, Ian Wood wrote:
>>
>>> filepro 5.07.03.02
>>> Windows Server 2008
>>>
>>> We currently run an overnight process that exports data from about 50
>>> files
>>> to feed another system.  Periodically, we get an invalid index error on
>>> one
>>> of the files, not one in particular, just a random spot.  I have the -ro
>>> flag set to run as read only.
>>>
>>> Is there a way to have rreport run on files and ignore automatic indexes?
>>> I'm not posting anything, just doing file dumps.
>>>
>>
>> If you're running with "-ro", then the problem isn't when updating an
>> index (which it won't do in read-only mode), but when reading an index.
>>   Assuming that the error doesn't occur on the temp index that *report
>> built, then I can only assume that the error occurred on a lookup.  (What
>> index did the error occur on?)  And the only index being accessed when
>> executing the lookup it the index being used for that lookup, which you
>> obviously can't avoid using.
>>
>>
>>   I don't have enough time to do a dxmaint -ra -e on all files first as we
>>> run two shifts and the exports take approximately 5-6 hours to run.
>>>
>>
>> If you are looking up to a file via a corrupted index, you may have no
>> choice but to rebuild that index.

-- 
Kenneth Brody