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