Running a report without indexes

[Ian Wood]

This is the command line

\fp\dreport gr_ap -fp file_dump -u -a -v file_dump_s -y none -ro -r "3CON"
-h "gr_ap"

No index is specified, and I can assure you that there are no lookups at
all in either the selection process (which does contain a call, but that's
only to set a date, again no lookup) nor the output process.

I guess I was just looking for a PFNOINDEX=ON or something of that ilk so
as not to even try to read any indexes.

On Tue, Mar 19, 2013 at 12:57 PM, Kenneth Brody <kenbrody at spamcop.net>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20130319/b81b8efd/attachment.html