Problems with Sort/Selection processing on associated fields.

John Esak john at valar.com
Fri Feb 13 10:25:42 PST 2009


You can only use SELECT once on the select table.  Well, that is to say
rather, you can only select the record one time while on a sort/select prc
table.

(I do not know what would happen if you did a lookup dash to yourself over
and over and hit a SELECT each time... Something for someone more curious
than me to try. :-)

John
 

> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
m] On Behalf Of GCC Consulting
> Sent: Friday, February 13, 2009 1:11 PM
> To: 'Boaz Bezborodko'; 'Kenneth Brody'
> Cc: filepro-list at lists.celestial.com
> Subject: RE: Problems with Sort/Selection processing on 
> associated fields.
> 
> 
> 
> > -----Original Message-----
> > From: 
> filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com
> >
> [mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.c
elestial.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
>   
> 
> 
> 
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 



More information about the Filepro-list mailing list