Problems with Sort/Selection processing on associated fields.

[Boaz Bezborodko]

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