processing issue
Richard D. Williams
richard at appgrp.net
Thu Feb 28 09:29:44 PST 2019
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>
More information about the Filepro-list
mailing list