browse lookup phenomenon - SOLVED!!!!!

[Dennis Malen]

Hopefully my experience will help someone.



My lookup browse phenomenon has been solved with the help of intuitive 
questions by Jeff Harrison who first put us in the right direction. That was 
followed up by Marc Brumlik, Richard Kreis and Ken Brody. Their e-mails 
asked me to report what edit type I was using for a dummy field identified 
as "rn".



I use "rn" in all my processing for a record number lookup. I identify it as 
rn=@rn.

I was always under the misguided impression that if you have a dummy field 
that was already defined that the dummy field would take on that 
characteristic. I not only use that concept for "rn" but for other dummy 
fields. I thought it always worked.



It was only recently that my staff brought to my attention that a number of 
browse lookups had never worked properly for years. After an investigation 
of which ones were not working properly we found that in every instance the 
browse lookup was executed from a "chained" processing table. It worked in 
"input" but not in "chain".



Why? The answer to my particular problem was that the lookup file for record 
number had an edit of (6,.0). In every case, whether the browse lookup 
resides in "input" or a "chain" process, it appears the proper approach is 
to always edit rn as rn(6,.0) to mirror the corresponding field. In my case 
it must contain the exact edit. Even if I edited it as rn(7,.0) it will not 
work. It must be exactly what the lookup file possesses.



All these years I thought I could use rn=@rn.



Why did it work in "input" and not in the "chained" processing table? We 
know that I copied the exact process over to "chain" from "input". It worked 
in "input" but not in "chain". Low and behold, the reason it work in "input" 
was that over the years where I have thousands of lines of processing, I had 
defined "rn" in another processing routine within "input" as rn(6,.0). I 
never remembered I did it nor did I look for it - obviously.



In addition, that is why it never worked in -z or a call statement, because 
I copied the exact processing without the rn(6,.0) which resided in another 
routine that had been foregotten. That edit was nowhere to be found in chain 
and hence the problem.



Again, I must take this opportunity to thank Jeff Harrison, Marc Brumlik, 
Richard Kreis and Ken Brody who stuck with me and pointed me in the right 
direction.



The list is great, filePro is great, you guys are great!



Sincerely,



Dennis Malen

516.479.5912