How to "ignore" records in a FIND procedure

Mike Palandri palandri at 4j.lane.edu
Tue Aug 22 10:13:26 CDT 2006


I've done it by reading a dummy key from a second file to force the Find 
procedure to fail.  The routine below skips Emp-Security-Table records if 
they are already displayed by doing a Get on Sub-Code-Dummy, a real code 
table in the application that hardly ever is written to.  The Get attempts 
to find a key that is not in the code table, "DUMMY", and  when it's not 
found, everything retrieved within the scope of the For Missing is 
abandoned, and the Find procedure moves to the next record of 
Emp-Security-Table.



FILE EMP-SECURITY-TABLE OCCURS 17 &
    PRIMARY &
    CACHE &
    OPEN 1 READ CLOSE
    ACCESS VIAINDEX EMP-SECURITY-KEY USING TC-SURNAME
    SELECT IF WLOC-CODE OF EMP-SECURITY-TABLE = TC-WLOC-CODE &
       OR TC-WLOC-CODE = "@"

FILE SUB_CODE_TBL ALIAS SUB_CODE_DUMMY &
    DESIGNER &
    OPEN 1 READ CLOSE

====================================

PROCEDURE FIND
BEGIN
    ; This temp is used to test for duplicates... we do not want to
    ; display the same employee twice, even though they may have more
    ; than one record in emp-security-table.
    LET TC-SV-EMP-NO = ""
    FOR MISSING EMP-SECURITY-TABLE
    BEGIN
       GET EMP-SECURITY-TABLE VIAINDEX EMP-SECURITY-KEY USING TC-SURNAME OPT
       IF ACCESSOK
       THEN BEGIN
          ; Now test if this record matches the passed employee type. If 
not the
          ; correct type, force find to fail by doing a get we know will fail
          LET TB-EMP-TYPE-FOUND = FALSE
          DO INTERNAL G010-TEST-TYPE
          ; Do not display if employee is not the correct type or they are
          ; already displayed.  IF they meet this test and are displayed,
          ; save their emp-no to test against the next possibility.
          IF TB-EMP-TYPE-FOUND = FALSE &
                OR TC-SV-EMP-NO = EMP-NO OF EMP-SECURITY-TABLE
             THEN GET SUB_CODE_DUMMY VIAINDEX SUB_CODE_KEY USING "DUMMY"
             ELSE LET TC-SV-EMP-NO = EMP-NO OF EMP-SECURITY-TABLE
       END
    END
END







At 09:03 PM 08/20/2006, fernando.olmos at hpa.com.au wrote:
>Content-Class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C6C4D6.C416C580"
>
>Hi everyone.
>
>How is it possible, with logic, to be able to ignore the occurrence of a 
>record being retrieved into a cluster, within a FIND procedure?
>
>Obviously the ACCESS and SELECT clauses at the FILE definition level is 
>the quick answer, but what if you require complex logic to determine, 
>based on details records, whether a record in a cluster should be included 
>or not ?
>
>i.e. Here is the rows on my screen ...
>         Account Number  Name
>         1234                    Customer A      -- this customer has 20 
> detail records where all records are not invoiced
>
>         1235                    Customer B      -- this customer has 10 
> detail records (orders) where 9 of 10 are flagged as invoiced and the 
> last rec is not invoiced
>
>         1236                    Customer C      -- this customer has 5 
> detail records where all records are invoiced.
>
>I want to use some logic to only display CUSTOMER B in the cluster, on the 
>screen.
>
>Fernando Olmos
>MIS
>Senior Analyst Programmer
>
>HPA
>Direct:  03 9217 5411
>Mobile: 0410 382 857
>Fax:     03 9217 5716
>
><file:///H:/Appdata/Microsoft/Signatures/www.hpa.com.au>www.hpa.com.au
>
>
>**********************************************************************
>IMPORTANT
>The contents of this e-mail and its attachments are confidential and intended
>solely for the use of the individual or entity to whom they are addressed.  If
>you received this e-mail in error, please notify the HPA Postmaster, 
>postmaster at hpa.com.au,
>then delete  the e-mail.
>This footnote also confirms that this e-mail message has been swept for the
>presence of computer viruses by Ironport. Before opening or using any
>attachments, check them for viruses and defects.
>Our liability is limited to resupplying any affected attachments.
>HPA collects personal information to provide and market our services. For more
>information about use, disclosure and access see our Privacy Policy at
>www.hpa.com.au
>**********************************************************************
>--
>= = = = = = = = = = = = = = = = = = = = = = = = = = = =
>Mailing list: powerh-l at lists.sowder.com
>Subscribe: &quot;subscribe&quot; in message body to 
>powerh-l-request at lists.sowder.com
>Unsubscribe: &quot;unsubscribe &lt;password&gt;&quot; in message body to 
>powerh-l-request at lists.sowder.com
>http://lists.sowder.com/mailman/listinfo/powerh-l
>This list is closed, thus to post to the list you must be a subscriber.
>Add 'site:lists.sowder.com powerh-l' to your search terms to search the 
>list archive at Google.


Mike
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20060822/e6880b28/attachment.html


More information about the powerh-l mailing list