<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
GCC Consulting wrote:
<blockquote cite="mid:00a101c86361$d704e960$850ebc20$@net" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: filepro-list-
<a class="moz-txt-link-abbreviated" href="mailto:bounces+gccconsulting=comcast.net@lists.celestial.com">bounces+gccconsulting=comcast.net@lists.celestial.com</a> [<a class="moz-txt-link-freetext" href="mailto:filepro">mailto:filepro</a>-
<a class="moz-txt-link-abbreviated" href="mailto:list-bounces+gccconsulting=comcast.net@lists.celestial.com">list-bounces+gccconsulting=comcast.net@lists.celestial.com</a>] On Behalf
Of Boaz Bezborodko
Sent: Wednesday, January 30, 2008 11:50 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:filepro-list@lists.celestial.com">filepro-list@lists.celestial.com</a>
Subject: Re: Could this be a bug in FilePro? (Was--Weird output with
associated field)
</pre>
<blockquote type="cite">
<pre wrap="">when I look at the code, I am also making some assumptions, but they
should be confirmed:
first, note as Ken White's suggested code shows, make sure to use
-nl for the lookup that tests if you've gone beyond your range
of records of interest.
</pre>
</blockquote>
<pre wrap="">I replaced the flag with the -nl and have the same problem, but I
expected this since the problem is occurring at the beginning of the
file.
</pre>
<blockquote type="cite">
<pre wrap="">Are ba and bb global (or have their expected values every time they
get to where they are tested as part of the conditional lookups)?
</pre>
</blockquote>
<pre wrap="">They are global and are listed in AUTO processing.
</pre>
<blockquote type="cite">
<pre wrap="">On both command line and in the lookups you are using letter o and
</pre>
</blockquote>
<pre wrap="">not
</pre>
<blockquote type="cite">
<pre wrap="">zero, right?
</pre>
</blockquote>
<pre wrap="">Right.
</pre>
<blockquote type="cite">
<pre wrap="">You say index "o" is built on date field "20". Is that also the same
edit and does the index go across ten bytes of that date field?
</pre>
</blockquote>
<pre wrap="">It is the same edit, though they are all (8,mdy/). In my field it is
'ai' that is incorrectly set to 10 bytes. But this shouldn't cause the
problem as it is at the end of the processing. Even with fixing this
the
error occurs. In stepping through with debug I've confirmed that the
first record chosen by the "LOOKUP -" is the record with which I have
the problem.
</pre>
<blockquote type="cite">
<pre wrap="">After checking all this, are you getting the expected # of
records selected?
</pre>
</blockquote>
<pre wrap="">No. Whenever I use this method I'm always off by the number of
populated
associated fields after the first one. So FilePro does a "SELECT" on
the
record as it should, but it is only adding the first associated field,
and not any subsequent ones, *in the first indexed record only*. If the
same record was to appear anywhere but first in the indexed order then
all the associated fields are added as records. And if a different
record with multiple associated fields populated is first in the
selection order then it will also have only the first associated field
selected as records for the output.
</pre>
<blockquote type="cite">
<pre wrap="">If you think selecting the right records, but still are not getting
the expected output, then post the output processing as well.
</pre>
</blockquote>
<pre wrap="">1 ------- - - - - - - - - - - - - - - - -
◄ If: ◄
Then: lookup glap k=A1 i=a -nx ◄
2 ------- - - - - - - - - - - - - - - - -
◄ If: not glap ◄
Then: beep;show "@ACCOUNT NUMBER NOT FOUND"&1 ◄
3 ------- - - - - - - - - - - - - - - - -
◄ If: ◄
Then: ab(36,*)=glap(2) ; ac(8,*)=glap(7) ; ad(48,*)=27 ; ◄
4 ------- - - - - - - - - - - - - - - - -
◄ If: 32="PAYROLL" ◄
Then: ae(1,*)="P" ◄
5 ------- - - - - - - - - - - - - - - - -
◄ If: ◄
Then: END ◄
6 ------- - - - - - - - - - - - - - - - -
Since there is no PRINT statement then all records that are selected
should appear on the report. But the error is occurring before this
part
of the process. If I used the indexing method then I get fewer records
selected then if I go through the whole file.
Boaz
_______________________________________________
Filepro-list mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Filepro-list@lists.celestial.com">Filepro-list@lists.celestial.com</a>
<a class="moz-txt-link-freetext" href="http://mailman.celestial.com/mailman/listinfo/filepro-list">http://mailman.celestial.com/mailman/listinfo/filepro-list</a>
</pre>
</blockquote>
<pre wrap=""><!---->
Have you tried a selection set using 20 eqf @td and -j on the command line?
This should select your records rapidly and avoid your -v selection processing but give you the selection speed you're looking for. Or at least
See if all of your records are being selected.
Richard Kreiss
GCC Consulting
<a class="moz-txt-link-abbreviated" href="mailto:rkreiss@gccconsulting.net">rkreiss@gccconsulting.net</a>
</pre>
</blockquote>
-J is an IUA command, not a report output command.<br>
<br>
Boaz<br>
</body>
</html>