i’m getting this pretty consistently:
field lastcost
formulafill lookupselected(‘pid’, ‘item’, item, ‘cost’, 0, 0)
causes panx to hang. not crash. i get an everlasting spinny and have to force quit.
the file ins’t huge. c. 20k records.
in this particular example the lookup is from the same database, but i’m getting the hang when the lookup is from a different database as well.
i do have a very similar procedure in a much smaller database, c. 300 records, and it works.
20,000 * 20,000 is 400,000,000. If the average lookup finds a match after looking through half the records, that’s 200,000,000 records looked at during the FormulaFill. That could take awhile. The Wrap option in the SuperLookup( function exists for just this reason. If you sort the item field and then
Field lastcost
FormulaFill superlookup("pid",{item="}+item+{"},{cost},"selected",true(),"wrap",true())
It won’t be starting each search from the top, but rather from the record where it last found a match.
If you are doing the lookup from another database, you would want to sort both item fields before doing the FormulaFill.
thanks for the lucid example of superlookup(. i’ll certainly give that a try. (my current workaround is a loop that takes several minutes.)
i understand the concept that a lookup in a 20k db will result in evaluating the function an average of 200k times, and that does sounds like a lot, but i can tell you from experience that pan6 accomplished this same task so quickly that i never noticed how long it took.
why is panx so much slower at this?
Probably mainly due to unicode character support.
i thought of that, but wondered if that could be the problem since the first 128 unicode characters are the same as ascii and the databases i’m use these characters almost exclusively.
There was a previous discussion regarding unicode relating to speed and why Panorama X must always operate using the unicode character set.
Sam, I would try the procedure on a smaller file - build in a time recorder and maybe try several different file sizes.