browse lookup phenomenon - SOLVED!!!!!

[Dennis Malen]

----- Original Message ----- 
From: "Kenneth Brody" <kenbrody at bestweb.net>
To: "Dennis Malen" <dmalen at malen.com>
Cc: "FilePro Mailing List" <filepro-list at lists.celestial.com>
Sent: Friday, March 24, 2006 2:58 PM
Subject: Re: browse lookup phenomenon - SOLVED!!!!!


> Quoting Dennis Malen (Fri, 24 Mar 2006 14:24:15 -0500):
>
>> Jean-Pierre,
>>
>> See paragraph 2 for your answer. Then read the rest of my posting. It
>> explains why I use to do it.
>
> Here's a perfect example of why inline quoting, with trimming, is far
> superior to top-posting.  (Well, at least it's only paragraph 2 that
> I have to count to, rather than, say, paragraph 37.)
Hopefully how I am responding to you correctly in this format. If not, let 
me know.
>
> [...]
>> > | 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.
> [...]
>
> I've read that paragraph several times, and I'm still not sure what you
> mean by it.
>
If I use a dummy field aa and do not edit it and I say that aa=9 and field 9 
possesses an edit of (6,.0) that aa will now take on that characteristic and 
also possess an edit of (6,.0). If that is still true that would not have 
solved my problem. I used rn=@rn. It was pointed out that has a field length 
of 8. That being the case my processing would fail as it must equal (6,.0) 
(in my case to match the target file in the browse lookup). As I said (7,.0) 
won't work nor will (5,.0) work. It must be (6,.0) if the target index uses 
(6,.0). Upon furthur review I do believe that a dummy field does take on the 
characteristic of an existing field such as aa=9, or aa=lookup(9) etc. My 
problem was that since @rn had a length of 8 I was doomed and the processing 
would not work properly. I believe that is the bottom line.

> If you give a dummy field a length and type, such as "rn(8,.0)", then
> the field will have that length and type.  If you don't give it any
> length and type, then it will take on the length and type of the value
> assigned to it.
>
> What was your "misguided impression" about this?  What did you think
> happened differently?
In this process I was not cognizant of the fact that the nonmatching field 
length in @rn would cause a problem as I thought it was always working in 
input processing without defining rn as rn(6,.0). Because it was defined in 
another routine in "input", I was not aware of the problem. The browse 
lookup was copied over exactly into the chained processing. I did not 
realize there was a problem with rn=@rn.
>
Any other questions, please let me know.
> --
> KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
> http://www.hvcomputer.com
> http://www.fileProPlus.com
>
>
>