processing issue
scooter6 at gmail.com
scooter6 at gmail.com
Thu Feb 28 12:45:44 PST 2019
I actually thought I've done this before in -v table - but makes sense what
you're saying about the index used
In this instance however, I wasn't changing field values for the index I
was using but it was still going back to the first record I selected after
I executed the 'select' command....so I must have something else wrong in
that code when I was trying it
On Thu, Feb 28, 2019 at 2:52 PM Bill Randall <breadran01 at gmail.com> 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/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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20190228/b124decd/attachment.html>
More information about the Filepro-list
mailing list