Filepro-list Digest, Vol 29, Issue 12

[Steve Bergman]

Boaz Bezborodko wrote:

>
>>
> Even though you are working on an indexed selection set you could be 
> doing numerous other lookups within the program.  The problem could 
> just as easily be a bug in the code that forces the process to go 
> through the entire file on a looped, indexed search instead of 
> terminating early when the search has gone past the search criteria.  
> If the lookup is nested in another process the time to complete the 
> task would grow exponentially with the growth of the data-set.
> For example:  Let's say you need to looking through invoices on the 
> basis of the check-number used to pay off the invoice for each check 
> number in a set.  If you do a lookup by check number you want to check 
> that the check number has gone past the number used in the search.  If 
> you don't you'll end up looking through the entire file before getting 
> out of the loop and doing the same thing on the next check number.  
> Cut off the search as soon as the check numbers are no longer equal 
> and the process is much, much faster.
>
>
Thank you for the help.  Nice to see that FP has such a thriving user 
community after all these years. (Most of my customers that use FP 
started out on Tandy Business Systems running Xenix with 5MB external 
hard drives, have used their application for years and years, and 
require *very* little support.  And they *never* talk about switching to 
anything else!)

I've looked over the table that seems to be taking fully 50% of the 
overall time.  The loops he is using are of the form:

-------
 If:                                                                   ?
Then: lookup opo = ho.order  k=1    i=A -nx
-------
oloop | If: not opo
Then: goto goon
-------
.
.
.
-------
If:
Then: goto oloop
-------
goon | If:
Then:
-------

That should exit the loop after all matching records have been 
processed, right?

One thing I just noticed, though, is a lookup loop on one table within a 
lookup loop on another table in this processing. 

Also, automatic processing occurs on a record every time it is accessed 
during output processing, right?  If the main table, and the subsidiary 
lookup tables all have automatic processing defined, and there is a 
lookup loop within a lookup loop within the main processing, that could 
handily explain the relative slowness of processing, couldn't it?

Thanks,
Steve