processing issue
Josh Reader
josh.reader at mercuryelectronics.com
Thu Feb 28 13:45:34 PST 2019
Last week I was changing the value of the indexed field in a lookup and came across issues with it losing its place in the index. The index was built on manufacturer name and I was updating multiple records in one table that had the same value. The problem was as soon as the manufacturer name in the first match of look up was updated, the index caused it to go to that new name in the index instead of the one that needed changed. That caused the code to stop since no more matches were found. To get my desired result I simply moved my loop to the lookup line itself instead of the "not lookup" line. That way it only changed the first record in the lookup, then performed the lookup all over again. This worked perfectly. Note this will only work if you are updating all matches or else it would get stuck in an endless loop. Here is the code of the subroutine. As you can see the location of the loop causes the lookup to start fresh again instead of getting the next record in the lookup.
loopPRT IF: ' Lookup to part by manufacturer name
THEN: lookup part k=4 i=D -npx
IF: not part ' Mfg not found, return
THEN: return
IF: part(41) ne 4 ' Mfg's no longer match, return
THEN: return
IF: ' Update manufacturer name
THEN: part(41)=2
IF: ' Perform the lookup again since updating moves the index location
THEN: goto loopPRT
Josh
-----Original Message-----
From: Filepro-list <filepro-list-bounces+josh.reader=mercuryelectronics.com at lists.celestial.com> On Behalf Of Richard D. Williams via Filepro-list
Sent: Thursday, February 28, 2019 3:28 PM
To: Bill Randall <breadran01 at gmail.com>; scooter6 at gmail.com
Cc: filePro Mailing List <filepro-list at lists.celestial.com>
Subject: Re: processing issue
Bill,
Very interesting technique.
I will keep that in mind.
Thanks,
Richard
BTW No automatic processing is executed either.
On 2/28/2019 1:52 PM, Bill Randall wrote:
> Not true, Richard
>
> We use -v processing to change record values all the time.
> The important thing is what you pointed out. Don't change the value
> of a field that is used as the index you are using.
>
> This saves filePro from having to process a record more than once.
> The records that pass -v processing are never selected. Only updated
> and the -v ends without selecting.
>
> Bill
>
> On 2/28/2019 12:29 PM, Richard D. Williams via Filepro-list wrote:
>> Yes, that is the point.
>>
>> There are two places one should never change values is a real field
>> on a record, automatic processing and any -V processing.
>>
>> Richard
>>
>> On 2/28/2019 8:43 AM, scooter6 at gmail.com wrote:
>>> Yes that's correct - and I actually thought about that but when I
>>> initially wrote this it 'seemed' to work as I wanted except at the
>>> 'end' of the processing it loops back into what I'm looking for as
>>> far as valid records my command is rreport filename -f CoverSheet -u
>>> -a -v select
>>>
>>> I will try to move the 'validation' part to CoverSheet and not in
>>> the 'select' processing table - I'll assume that's what you're
>>> referring to
>>>
>>>
>>> On Thu, Feb 28, 2019 at 9:21 AM Richard D. Williams
>>> <richard at appgrp.net <mailto:richard at appgrp.net>> wrote:
>>>
>>> I suggest you use a msgbox yar(@RN) right after your "not yar"
>>> line.
>>>
>>> Oops, I think I found it. This seems like a -V table, correct?
>>> In your code you are changing the value of the record you are
>>> on;
>>> "90":438=cli(17);430=430{cli(17);cli(17)=cli(17)+"1";write:
>>>
>>> This is probably changing the index you loaded on your menu line
>>> and therefore moving you to a different location on the index.
>>> The next record would be one that would not be valid.
>>>
>>> -V code is meant to be used to select/sort only, not to change
>>> real field values on any record.
>>> The associated output processing table would be the place for
>>> these value changes.
>>>
>>> Please send me the full menu command you are using.
>>> You have a basic design issue here that can be resolved quickly
>>> once the full purpose is known.
>>>
>>> Happy to help. You can call me directly at (713) 931-9938.
>>>
>>> Richard D. Williams
>>>
>>>
>>>
>>> On 2/28/2019 7:18 AM, scooter6 at gmail.com
>>> <mailto:scooter6 at gmail.com> wrote:
>>>> Duly noted - I fixed that part as well
>>>>
>>>> But still getting same issue - runs through the records that
>>>> are
>>>> 'validated' but then starts over and it says Number Already
>>>> Assigned on the first record it assigned the number to during
>>>> the
>>>> process itself?
>>>>
>>>> Index being used is just a normal index
>>>>
>>>> On Wed, Feb 27, 2019 at 10:54 PM Richard D. Williams via
>>>> Filepro-list <filepro-list at lists.celestial.com
>>>> <mailto:filepro-list at lists.celestial.com>> wrote:
>>>>
>>>> It also loks to me that youo have another error in your logic.
>>>>
>>>> Here you do a lookup using key fb with exact match. I
>>>> assume
>>>> you only
>>>> want to evaluate records where fb eq yar(431).
>>>> Is index E build on 431?
>>>> If yes than see the adjusted code below.
>>>>
>>>> valid::lookup yar = PDM k=fb i=E -nx:
>>>> yarloop:not yar:goto counted:
>>>> :yar(437) ne fa:goto counted:
>>>> :yar(431) ne fb:getnext yar;goto yarloop:
>>>>
>>>>
>>>> valid::lookup yar = PDM k=fb i=E -nx:
>>>> yarloop:not yar:goto counted:
>>>> :yar(431) ne fb:goto counted:
>>>> :yar(437) ne fa:getnext yar;goto yarloop:
>>>>
>>>> Richard D. Williams
>>>>
>>>> On 2/27/2019 1:35 PM, scooter6--- via Filepro-list wrote:
>>>> > Doh - true story
>>>> > After fixing that - it does still do the first record
>>>> correctly, then it
>>>> > shows error on that same first record 'Number Already
>>>> Assigned'
>>>> > So that tells me it's not getting to the next record even
>>>> after the
>>>> > 'validation' part....
>>>> > Hmm.....
>>>> >
>>>> > On Wed, Feb 27, 2019 at 2:09 PM Bill Randall
>>>> <breadran01 at gmail.com <mailto:breadran01 at gmail.com>> wrote:
>>>> >
>>>> >> I am not sure but I do notice one thing.
>>>> >>
>>>> >> Your message box statements are showing you the
>>>> incorrect
>>>> data.
>>>> >>
>>>> >> :yar(438) ne "":msgbox "Problem with"<14<15<"Number
>>>> Already Assigned";exit:
>>>> >>
>>>> >> I believe, based on your code, that you really want
>>>> 14<15
>>>> to really be
>>>> >> yar(14)<yar(15)
>>>> >>
>>>> >> Just that alone may shed some light on your data.
>>>> >>
>>>> >> Bill
>>>> >>
>>>> >>
>>>> >> On 2/27/2019 1:59 PM, scooter6--- via Filepro-list wrote:
>>>> >>> I am trying to make a processing table that takes two
>>>> pieces of
>>>> >> information
>>>> >>> from the end user - then counts and validates those
>>>> records before
>>>> >>> proceeding
>>>> >>> For some reason that I can't find it goes 'backwards'
>>>> (in
>>>> my mind
>>>> >> anyways -
>>>> >>> I'm sure whoever may look at this and say it's not
>>>> backwards it's your
>>>> >> code
>>>> >>> - I get it haha)
>>>> >>> After it selects the first valid record, it does what
>>>> it's supposed to do
>>>> >>> but on the 2nd record it catches one of the 'validation'
>>>> issues that I'm
>>>> >>> filtering through first...if that makes sense
>>>> >>> First record, it grabs data from client file if it
>>>> passes
>>>> and does
>>>> >>> everything right, but the 2nd record it says a field is
>>>> not empty (but it
>>>> >>> is)
>>>> >>> Here is my code:
>>>> >>>
>>>> >>> :fa="":input fa(5,0RJ,g) "Enter Client Number ":
>>>> >>> :fb="":input fb(8,mdy/,g) "Enter Placement Date ":
>>>> >>> :fa="" or fb="":exit:
>>>> >>> ::goto valid:
>>>> >>> ::end:
>>>> >>> valid::lookup yar = PDM k=fb i=E -nx:
>>>> >>> yarloop:not yar:goto counted:
>>>> >>> :yar(437) ne fa:goto counted:
>>>> >>> :yar(431) ne fb:getnext yar;goto yarloop:
>>>> >>> :yar(438) ne "":msgbox "Problem with"<14<15<"Number
>>>> Already Assigned";exi
>>>> >>> t:* SECOND RECORD FOUND ERRORS HERE*
>>>> >>> :yar(432)="":msgbox "Problem with"<14<15<"No DOO";exit:
>>>> >>> :yar(435)="" or yar(435)=".00":msgbox "Problem
>>>> with"<14<15<"No Balance or
>>>> >>> Zero B
>>>> >>> alance";exit:
>>>> >>> :yar(14)="":msgbox "Problem with"<14<15<"No First
>>>> Name";exit:
>>>> >>> :yar(15)="":msgbox "Problem with"<14<15<"No Last
>>>> Name";exit:
>>>> >>> :yar(23)="":msgbox "Problem with"<14<15<"No Address";exit:
>>>> >>> :yar(24)="":msgbox "Problem with"<14<15<"No City";exit:
>>>> >>> :yar(25)="":msgbox "Problem with"<14<15<"No State";exit:
>>>> >>> :yar(26)="":msgbox "Problem with"<14<15<"No Zip";exit:
>>>> >>> :yar(439) ne "01" and yar(439) ne "66":msgbox "Problem
>>>> >> with"<14<15<"Status
>>>> >>> is"<y
>>>> >>> ar(439);exit:
>>>> >>> :yar(437)=fa and yar(431)=fb:x(10,.0,g)=x+"1":
>>>> >>> ::getnext yar;goto yarloop:
>>>> >>> ::end:
>>>> >>> counted:x="0":msgbox "No Records Selected";exit:
>>>> >>> :fc="":input popup fc(1,yesno,g)"I found"<x<"Accounts -
>>>> Is this correct?
>>>> >> ":
>>>> >>> :fc ne "Y":exit:
>>>> >>> ::goto client:
>>>> >>> ::end:
>>>> >>> client::lookup cli = client k=437 i=A -nx:
>>>> >>> :not cli:msgbox "Client"<437<"Not Found!";exit:
>>>> >>> :cli(72)="90":msgbox "Client"<437<"is Inactive!";exit:
>>>> >>> :cli and cli(72) ne
>>>> >>>
>>>> "90":438=cli(17);430=430{cli(17);cli(17)=cli(17)+"1";write:
>>>> >>> ::end:
>>>> >>> ::goto selectm:
>>>> >>> selectm:437=fa and 431=fb and 438 ne "":select;end:
>>>> >>>
>>>> >>> So everything works fine- it correctly finds 3 records
>>>> that meet my
>>>> >>> criteria
>>>> >>> The first record it finds, it adds data from 'client'
>>>> lookup, increments
>>>> >> it
>>>> >>> by 1 and does what it's supposed to - 2nd record (that
>>>> has already passed
>>>> >>> validation in my eyes) then says 'Problem with Mary
>>>> Smith
>>>> Number Already
>>>> >>> assigned'
>>>> >>> But after the error, if I go look at the record, that
>>>> field is empty...?
>>>> >>>
>>>> >>> Does anyone see an issue with what I'm doing in this
>>>> processing table?
>>>> >>>
>>>> >>> I'm running this as rreport filename -f CoverSheet
>>>> -u
>>>> -a -v select
>>>> >>> (the above code is in my select processing table - then
>>>> it's supposed to
>>>> >>> pass those records to CoverSheet)
>>>> >>>
>>>> >>> Thanks
>>>> >>>
>>>> >>> Scott
>>>> >>> PDM
>>>> >>> -------------- next part --------------
>>>> >>> An HTML attachment was scrubbed...
>>>> >>> URL: <
>>>> >>
>>>> http://mailman.celestial.com/pipermail/filepro-list/attachments/201
>>>> 90227/82205474/attachment.html
>>>>
>>>> >>> _______________________________________________
>>>> >>> Filepro-list mailing list
>>>> >>> Filepro-list at lists.celestial.com
>>>> <mailto:Filepro-list at lists.celestial.com>
>>>> >>> Subscribe/Unsubscribe/Subscription Changes
>>>> >>>
>>>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>>> >>
>>>> >> ---
>>>> >> This email has been checked for viruses by Avast
>>>> antivirus
>>>> software.
>>>> >> https://www.avast.com/antivirus
>>>> >>
>>>> >>
>>>> > -------------- next part --------------
>>>> > An HTML attachment was scrubbed...
>>>> > URL:
>>>> <http://mailman.celestial.com/pipermail/filepro-list/attachments/20
>>>> 190227/bd52e8dc/attachment.html>
>>>>
>>>> > _______________________________________________
>>>> > Filepro-list mailing list
>>>> > Filepro-list at lists.celestial.com
>>>> <mailto:Filepro-list at lists.celestial.com>
>>>> > Subscribe/Unsubscribe/Subscription Changes
>>>> >
>>>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>>> >
>>>>
>>>>
>>>>
>>>> ---
>>>> This email has been checked for viruses by AVG.
>>>> https://www.avg.com
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL:
>>>> <http://mailman.celestial.com/pipermail/filepro-list/attachments/20
>>>> 190227/a44f222a/attachment.html>
>>>>
>>>> _______________________________________________
>>>> Filepro-list mailing list
>>>> Filepro-list at lists.celestial.com
>>>> <mailto:Filepro-list at lists.celestial.com>
>>>> Subscribe/Unsubscribe/Subscription Changes
>>>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>>>
>>>
>>>
>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link
>>> &utm_campaign=sig-email&utm_content=emailclient>
>>>
>>> Virus-free. www.avg.com
>>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link
>>> &utm_campaign=sig-email&utm_content=emailclient>
>>>
>>>
>>>
>>> <#m_-5512988116758715792_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>
>> -------------- next part -------------- An HTML attachment was
>> scrubbed...
>> URL:
>> <http://mailman.celestial.com/pipermail/filepro-list/attachments/2019
>> 0228/9e0eb91f/attachment.html>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> Subscribe/Unsubscribe/Subscription Changes
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
Subscribe/Unsubscribe/Subscription Changes http://mailman.celestial.com/mailman/listinfo/filepro-list
More information about the Filepro-list
mailing list