Problems with Sort/Selection processing on associated fields.

[Boaz Bezborodko]

GCC Consulting wrote:
>   
>> -----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
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. 

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.

Boaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20090213/83c150c6/attachment.html