browse lookup phenomenon - SOLVED!!!!!

[Jean-Pierre A. Radley]

Dennis Malen propounded (on Fri, Mar 24, 2006 at 01:26:37PM -0500):
| 
| 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.


Since the very first days of filePro, the system field @RN (the current
record number) has been an integer field with length 8 ; why do you keep
trying to utilize it as if it were (6,.0) ??

-- 
JP
	==> http://www.frappr.com/cusm <==