processing issue
Bill Randall
breadran01 at gmail.com
Thu Feb 28 11:52:01 PST 2019
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/20190227/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/20190227/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/20190227/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/20190228/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
More information about the Filepro-list
mailing list