FW: Browse Lookups - WARNING....Long rambling post....read at your discretion

[Scott Walker]

Thanks to all for your responses to my browse lookup issue.

I've decided that the browse lookup feature just is not right for this task so I'll do a bit of coding.  I am scanning a LOT of records looking for any record where the Description field contains a specified string of text anywhere in the  Description field

The browse lookup is not optimal in this situation since there are hundreds of thousands of records and I am looking at each to see if a particular field contains a specified string of data anywhere in the field.  So I am looking up a record and seeing if  lookup(2) co "XYX123".  If not I use the "drop" command to eliminate it from the browse lookup.  Since there is no index that can be used to narrow down the number of records I am having to look at, I am just using the index built on order date.  The string of text may be found in one of the very first records I look at and not found again until hundreds of thousands of records later or perhaps not be found at all.

So this brings up the issue of whether there is a more efficient way to do this?

One thought, when I write the record with the order description, let's say for Order# 555555,  I could  write some addition records in a file that exists just to make the searching for a specified string faster.
For example, if the Description field contains "12345XYZ123" I would write these records to the extra file:

	Desc "key"	Order#
	12345		555555
	2345X		555555
	345XY		555555
	45XYZ		555555
	XYZ12		555555	
	YZ123		555555
	ZI23		555555
	123		555555
	23		555555
	3		555555

That would allow me to build an index on the 5 character description "key" string, and when the user asked for anything containing the string "XYZ123" I could use the first 5 characters of their request to narrow down the searched records to those in the index with the desc key of XYZ12.  That would give me the order numbers to look at in the regular file.

Is the overhead of this going to kill me.....for example, on a given order, we can have up to 999 line items with up to 99 lines of description per line item, with each line of description allowing up to 54 chararcters.  

Am I better off trying to come up with something outside of fp....some sort of user call to an outside program that scans the key file looking for the specified string and returns the fp record numbers for me to look at inside fp?

Regards,
Scott Walker




-----Original Message-----
From: Filepro-list [mailto:filepro-list-bounces+scottwalker=ramsystemscorp.com at lists.celestial.com] On Behalf Of Bruce Easton via Filepro-list
Sent: Tuesday, June 26, 2018 1:58 PM
To: filepro-list at lists.celestial.com
Subject: Re: Browse Lookups

"Events are a much better methodology [than timers]"

Agreed.  I work almost exclusively with browser-based projects anymore, so  I had to test this:

If:  @sk EQ "DTAB"

to be sure that you can't trap the PageDown as a browse-lookup trigger.


On 6/26/18 1:45 PM, Paul McNary via Filepro-list wrote:
> I like the idea of callbacks in filePro! :-)
>
>
> On 6/26/2018 11:17 AM, Fairlight via Filepro-list wrote:
>> On Tue, Jun 26, 2018 at 11:38:36AM -0400, Richard Kreiss via 
>> Filepro-list thus spoke:
>>> I would love to be able to set a timer for a browse which would 
>>> execute a sub-routine.
>> You're thinking very old-school.
>>
>> What would be better than a timer is a set of configurable callbacks 
>> which execute processing table segments upon various events.
>>
>> * Begin lookup
>> * Changed record
>> * End of matches
>> * Close lookup
>>
>> In this fashion, you can configure what you like, without having to 
>> rely on an arbitrary timer which may be smaller than desirable, or 
>> larger than necessary (thus wasting time).  Timers generally suck, to 
>> put it bluntly.
>> They're often too crude a tool.  Events are a much better methodology 
>> for this sort of functionality.
>>
>> And lo and behold, filePro already supports events in general terms. 
>> So why not have @brsbeg, @brsrcd, @brsend, and @brscls as 
>> system-based events which function like conventional callbacks?
>>
>> m->
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes 
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
Subscribe/Unsubscribe/Subscription Changes http://mailman.celestial.com/mailman/listinfo/filepro-list