<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
GCC Consulting wrote:
<blockquote cite="mid:005601c98e06$728a1610$579e4230$@net" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:filepro-list-bounces+gccconsulting=comcast.net@lists.celestial.com">filepro-list-bounces+gccconsulting=comcast.net@lists.celestial.com</a>
</pre>
</blockquote>
<pre wrap=""><!---->[<a class="moz-txt-link-freetext" href="mailto:filepro-list-bounces+gccconsulting=comcast.net@lists.celestial.com">mailto:filepro-list-bounces+gccconsulting=comcast.net@lists.celestial.com</a>]
On
</pre>
<blockquote type="cite">
<pre wrap="">Behalf Of Boaz Bezborodko
Sent: Friday, February 13, 2009 12:05 PM
To: Kenneth Brody
Cc: <a class="moz-txt-link-abbreviated" href="mailto:filepro-list@lists.celestial.com">filepro-list@lists.celestial.com</a>
Subject: Re: Problems with Sort/Selection processing on associated fields.
Kenneth Brody wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Quoting Boaz Bezborodko (Thu, 12 Feb 2009 16:26:08 -0500):
[...]
</pre>
<blockquote type="cite">
<pre wrap="">OK, trying to keep track of the data by counting the occurrences
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->doesn't
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">work because a) they are sometimes entered out of order and b) there
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->are
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">sometimes blank fields in the middle. This means that even though you
can select a specific record from the index the Sort/Selection process
cannot tell you which associated field is the one that that index
points to.
Am I wrong in thinking that this is a bug?
</pre>
</blockquote>
<pre wrap="">Short answer: Yes. :-)
Long answer:
What if more than one member of the group met the selection criteria?
What
if none of them did, but the record was selected because of some other
"OR"
part of the selection set?
However, if you are also sorting on that group, then the selection
will be
based solely on the individual members of the group as they are entered
into the sort, and @AF will point to that particular member. (Of
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->course,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">the above two scenarios come into play as well.)
</pre>
</blockquote>
<pre wrap="">I was thinking about this last night and the reason I would want @AF is
to find out what was in the index that made put it in the order. IOW,
if I have two records with the data "12/31/08","1234","0987" (1st
instance of A1) and "12/31/08","1234","8765" (3rd instance of A1 with
not 2nd instance of A1) and the last piece of data comes from associated
field A1, then how can I find out that the particular record I am
looking at at any given moment is from the record with the associated
field "0987" as opposed to "8765"?
Currently A1 will always show "8765" and there is no way to find out
what is indexed version of that instance of the
record. With the 2nd instance of A1 being blank the Sort/Selection
processing on the index will simply not show as a separate 'record'. It
will go through 2 versions of record "1234" with no easy way of finding
out which is which.
I'm not sure how much demand there is for a way of doing so, but is it
very difficult to add system fields that return the actual data in each
of the fields used in sort for that particular record? Say an @I1, @I2,
@I3, etc. for the data on which the order of the index being worked on
is established. Therefore @I1 would be "12/31/08", @I2 would be "1234"
and @I3 would be either "0987" or "8765" depending on which version of
the record you are looking at.
(Right now to solve my problem I have to build and work with a
completely different file that breaks out all the data. This could be
how the system should originally have been written, but I am using a
legacy program and the way the company works now requires more
flexibility back when it was written. Still, I think this is the second
time I've come across this particular obstacle.)
Boaz
</pre>
</blockquote>
<pre wrap=""><!---->
Since you are working with a sort/selection process, you could read the
associated fields and load any values into an array to remove any blanks.
The select the record using the first element or the array. Increment the
index by one and check to see if there is a value present. If the is select
the record again using this value.
????: if:
Then:
If:
Then:Sort1=array[ct],sort2=xxxx;sort3=yyyy
If: array[ct+"1"] ne ""
Then:ct=ct+"1";GOTO ????
I have not tested this idea.
Richard Kreiss
GCC Consulting
<a class="moz-txt-link-abbreviated" href="mailto:rkreiss@gccconsulting.net">rkreiss@gccconsulting.net</a></pre>
</blockquote>
I guess my complaint is that with an index built on an associated field
there is no way for the process to know what index it is on. <br>
<br>
There are times when you want to know this and it is used quite often,
for example, to move quickly to specific points in the file like when
sorting by date so that you can move to the first and last date in the
selection before and after rolling through each one individually. But
with an index built on an associated field you can't do that without
building some form of sort/selection routine on an array in the process
table itself.<br>
<br>
Boaz
</body>
</html>