browse lookup phenomenon

[Dennis Malen]

Ken,

I'm sorry if I have not been clear. I thought I was.

Let me recap. Processing created on the input table with an @key works fine. 
If it is chained, called or I use -z it does not work. The -z also uses the 
@key.

I am in the process of printing the screens so you can see what I mean.

Dennis
----- Original Message ----- 
From: "Kenneth Brody" <kenbrody at bestweb.net>
To: "Dennis Malen" <dmalen at malen.com>
Cc: <filepro-list at lists.celestial.com>
Sent: Thursday, March 23, 2006 12:52 PM
Subject: Re: browse lookup phenomenon


> Quoting Dennis Malen (Thu, 23 Mar 2006 12:40:32 -0500):
>
>> Ken,
>>
>> It does not work nor does a call statement work. Input always works.
>
> So, if you have a processing called "foo", and you chain to it via
> CHAIN "foo", the browse lookup doesn't work.  But, if you run it using
> "-z foo" on the command line, it works?
>
>> I can see the information on the first pass but I scroll up it starts to
>> show me prior records. When I scroll back down to try to see the first
>> record it only takes me to the record that is at the bottom of the
>> screen. I can never get back to the first record unless I exit the
>> processing and reexecute.
>>
>> Again, it was always the case for all my prior browse lookups that were
>> executed by the chain statement. The people on the floor were always
>> aware of it and thought that was the way it worked untill someone
>> brought it to my attention and inquired why some browses worked and and
>> some did not. After further investigation we confirmed that the chained
>> statement was the culprit.
> [...]
>
> Given that no one else has duplicated this behavior, I still need an
> explicit answer to my explicit question, which I have yet to receive
> after asking several times.
>
> --
> KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
> http://www.hvcomputer.com
> http://www.fileProPlus.com
>
>
>