browse lookup phenomenon - SOLVED!!!!!

[Fairlight]

At Fri, Mar 24, 2006 at 02:13:14PM -0500 or thereabouts, 
suspect J. P. Radley was observed uttering:
> Dennis Malen propounded (on Fri, Mar 24, 2006 at 01:26:37PM -0500):
> | 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) ??

So much for his "accurate" diagnosis of what conditions -must- exist in
order to elicit the desired behaviour.  If that's true, and he's still
using 6, then his statement about it having to be -exactly- what the lookup
file possesses is incorrect.  Which is an example of extremely fine-tuned,
high-quality, accurate systems analysis at its finest; obviously a lot of
love and craftsmanship went into both the first umpteen 'bug' reports, not
to mention the resolution post. :)  [There should be an "X-Made-In: Russia"
header on most of those, probably.]

Ah well.  Probably in for another 20+ messages trying to figure out the
-real- cause and solution.  Or maybe not.  Could be a, "It works now, I
don't give a damn how," type situation.  Or it could be a 40+ message, "I
thought it worked, but now it doesn't work when...," type of continuation,
where Ken is -forced- to ask (repeatedly), "WHAT doesn't work?"

Ah, free entertainment in the workplace.  Love it.

m->