processing issue
Richard D. Williams
richard at appgrp.net
Thu Feb 28 12:28:00 PST 2019
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/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