Problems with Sort/Selection processing on associated fields.

[GCC Consulting]

> -----Original Message-----
> From: filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com
>
[mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com]
On
> Behalf Of Boaz Bezborodko
> Sent: Friday, February 13, 2009 12:05 PM
> To: Kenneth Brody
> Cc: filepro-list at lists.celestial.com
> Subject: Re: Problems with Sort/Selection processing on associated fields.
> 
> Kenneth Brody wrote:
> > Quoting Boaz Bezborodko (Thu, 12 Feb 2009 16:26:08 -0500):
> > [...]
> >> OK, trying to keep track of the data by counting the occurrences
doesn't
> >> work because a) they are sometimes entered out of order and b) there
are
> >> 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?
> >
> > 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
course,
> > the above two scenarios come into play as well.)
> >
> 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

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
rkreiss at gccconsulting.net