<html>
<body>
<font size=3>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.<br><br>
<br><br>
</font><font face="Courier New, Courier" size=2>FILE EMP-SECURITY-TABLE
OCCURS 17 &<br>
PRIMARY &<br>
CACHE &<br>
OPEN 1 READ CLOSE<br>
ACCESS VIAINDEX EMP-SECURITY-KEY USING TC-SURNAME<br>
SELECT IF WLOC-CODE OF EMP-SECURITY-TABLE = TC-WLOC-CODE
&<br>
OR TC-WLOC-CODE = "@"<br><br>
FILE SUB_CODE_TBL ALIAS SUB_CODE_DUMMY &<br>
DESIGNER &<br>
OPEN 1 READ CLOSE<br><br>
</font><font size=3>====================================<br><br>
</font><font face="Courier New, Courier" size=2>PROCEDURE FIND<br>
BEGIN<br>
; This temp is used to test for duplicates... we do not want
to<br>
; display the same employee twice, even though they may have
more<br>
; than one record in emp-security-table.<br>
LET TC-SV-EMP-NO = ""<br>
FOR MISSING EMP-SECURITY-TABLE<br>
BEGIN<br>
GET EMP-SECURITY-TABLE VIAINDEX
EMP-SECURITY-KEY USING TC-SURNAME OPT<br>
IF ACCESSOK<br>
THEN BEGIN<br>
; Now test if this
record matches the passed employee type. If not the<br>
; correct type, force
find to fail by doing a get we know will fail<br>
LET TB-EMP-TYPE-FOUND =
FALSE<br>
DO INTERNAL
G010-TEST-TYPE<br>
; Do not display if
employee is not the correct type or they are<br>
; already
displayed. IF they meet this test and are displayed,<br>
; save their emp-no to
test against the next possibility.<br>
IF TB-EMP-TYPE-FOUND =
FALSE &<br>
OR TC-SV-EMP-NO = EMP-NO OF EMP-SECURITY-TABLE<br>
THEN
GET SUB_CODE_DUMMY VIAINDEX SUB_CODE_KEY USING "DUMMY"<br>
ELSE
LET TC-SV-EMP-NO = EMP-NO OF EMP-SECURITY-TABLE<br>
END<br>
END<br>
END<br><br>
<br><br>
<br><br>
<br><br>
</font><font size=3>At 09:03 PM 08/20/2006, fernando.olmos@hpa.com.au
wrote:<br>
<blockquote type=cite class=cite cite="">Content-Class:
urn:content-classes:message<br>
Content-Type: multipart/alternative;<br>
<x-tab> </x-tab>
boundary="----_=_NextPart_001_01C6C4D6.C416C580"<br><br>
</font><font size=2>Hi everyone.</font><font size=3> <br><br>
</font><font size=2>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?<br>
</font><font size=3><br>
</font><font size=2>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 ?<br>
</font><font size=3><br>
</font><font size=2>i.e. Here is the rows on my screen
...</font><font size=3> <br>
</font><font size=2>Account
Number Name</font><font size=3> <br>
</font><font size=2>
1234
Customer A -- this customer has 20 detail
records where all records are not invoiced<br>
</font><font size=3><br>
</font><font size=2>
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<br>
</font><font size=3><br>
</font><font size=2>
1236
Customer C -- this customer has 5 detail
records where all records are invoiced.</font><font size=3> <br><br>
</font><font size=2>I want to use some logic to only display CUSTOMER B
in the cluster, on the screen.</font><font size=3> <br><br>
</font><font size=4 color="#0000FF"><i>Fernando
Olmos</i></font><font size=3> <br>
</font><font size=2><b>MIS</b></font><font size=3> <br>
</font><font size=2><b>Senior Analyst Programmer</b></font><font size=3>
<br><br>
</font><font size=2 color="#0000FF"><b>HPA</b></font><font size=3><br>
</font><font size=2>Direct: 03 9217 5411</font><font size=3><br>
</font><font size=2>Mobile: 0410 382 857</font><font size=3><br>
</font><font size=2>Fax: 03 9217
5716</font><font size=3> <br><br>
</font><font size=2 color="#0000FF"><b><u>
<a href="file:///H:/Appdata/Microsoft/Signatures/www.hpa.com.au">
www.hpa.com.au</a></u></b></font><font size=3> <br><br>
<br>
</font><pre>
**********************************************************************
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@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
<a href="http://www.hpa.com.au/" eudora="autourl">www.hpa.com.au</a>
**********************************************************************
</pre><font face="Courier New, Courier" size=3></font>-- <br>
= = = = = = = = = = = = = = = = = = = = = = = = = = = =<br>
Mailing list: powerh-l@lists.sowder.com<br>
Subscribe: &quot;subscribe&quot; in message body to
powerh-l-request@lists.sowder.com<br>
Unsubscribe: &quot;unsubscribe &lt;password&gt;&quot; in
message body to powerh-l-request@lists.sowder.com<br>
<a href="http://lists.sowder.com/mailman/listinfo/powerh-l" eudora="autourl">
http://lists.sowder.com/mailman/listinfo/powerh-l</a><br>
This list is closed, thus to post to the list you must be a
subscriber.<br>
Add 'site:lists.sowder.com powerh-l' to your search terms to search the
list archive at Google. </blockquote>
<x-sigsep><p></x-sigsep>
<br>
Mike<br>
.<br>
</body>
</html>