Conference iosg::all-in-1_v30

    Good question. (btw, do you mean DEPART in PROFILE).
    
    I'm also looking for a solution to that problem *without* programming
    several loops.
    
    Sjaak.

Hi,

The problem with the /UNIQUE or 'FOR UNIQUE' is that once it finds another
value, a former value is not taken into consideration again. E.g.: 

	Simon
	Simon
	Simon1
	Simon
	Simon
	Simon2

/UNIQUE and 'FOR UNIQUE' show:

	Simon
	Simon1
	Simon
	Simon2

A trivial example is included. It first sorts the field and then uses the 'FOR 
UNIQUE' (it's only one FOR loop).

HTH,

	Simon.



;;.TYPE;;

ENTRY /MODE=UPDATE
/HARD='Your Entry Form Title'

;;.FILE;;

OAUSER:TEST.DAT,FIELD_1

;;FIELD_1;;

/HARD="Description of field 1 (Key)"

;;FIELD_2;;

/RECOG=<GET #FIELD_2 = FIELD_2 \XOP "~~RECOG~~"
/HARD="Description of field 2"

;;FIELD_3;;

/HARD="Description of field 3"

;;~~RECOG~~;;

BIND/SORT=".FIELD_2" *FIELD TO TEST WITH .FIELD_2 ENS #FIELD_2 \
FORM AUTO SELECT FOR UNIQUE FIELD_2 *FIELD DO 
  SEL_CHOICE OA$SEL_LINE:3 .FIELD_2 /STYLE=CHOICE\    
GET #FIELD_TMP = *FIELD.FIELD_2[OA$SEL_KEY] \
.IF OA$SRC_COUNT EQ 0
 THEN
  DISPLAY No item satisfied the search criteria
 ELSE
  .IF #FIELD_TMP EQS ""
   THEN
    DISPLAY No item was selected 
   ELSE
    DISPLAY 1 item found and selected \
FORCE \
CLOSE_PRIOR \
.IF #FIELD_TMP NES "" THEN GET FIELD_2 = #FIELD_TMP \
BIND_BREAK *FIELD                                   

	As .2 notes, the mechanism for doing what you want in ALL-IN-1 is the
/UNIQUER qualifier.  However, unless the records are in order by the field you
are FINDing on (bad grammar!), you'll get the symptom that .2 describes.

	This, BTW, is not really an ALL-IN-1 limitation; *anytime* you want to
see only one instance of a value for a field (without writing extensive program-
ming to do so), you'd have to make sure that that field was one of the keys to
the file.  That's just the way RMS works.  Now, if you can make that field a key,
then combining that with the /UNIQUE qualifier, you'll have everything you need.

	F

Re .-1

    Would it work properly if the field(s) I wanted to search on had an
    index applied to them?  This way, they would be sorted and thus we
    would not see a repeated value. (does this make any sense?)  Is there
    an effective limit to the number of indexes that one can put on an RMS
    data file?  There are already several indexes on this filie and the
    customer is a little reluctant to put too many more on.  If too many
    indexes are placed on a file, does it impede its accessability &
    performance?

    Thanks for the extensive replies.  RE .1, the file I have in mind is
    not the PROFILE data file but is a data file which is part of a
    sub-system created a few months ago for this customer.  
    
    /dvi

�    Would it work properly if the field(s) I wanted to search on had an
�    index applied to them?  This way, they would be sorted and thus we
�    would not see a repeated value. (does this make any sense?)

	That's what I was saying in .3.  If you'll make the appropriate field(s)
RMS key(s), then the /UNIQUE qualfier should do what you want.

	As far as an "effective limit" on the number of RMS keys, it's really a
performance issue, not an internal limit.  Each key that you add will generate
extra overhead *for every record* in your data file.  This not only means larger
files, but each time a record is added/deleted/updated, it means more work to
update all of the key information as well (since modifying any of those fields
could, in effect, be changing the alternate keys).

	F

    Actually, there is a limit - 255 I think.
    
    But, as .5 says, performance limits you earlier than that. 
    
    (Note that there is only a tiny effect on the performance of Read
    operations. So, if it's a file where updates, additions and deletions
    are rare compared to reads, the performance effect may not be enough to
    matter).
    
    Dave.

    Of course you could do a BIND/SORT to get the dataset in the
    appropriate oder, then do the FOR UNIQUE against the bound set. No
    need for a RMS key - but performance may suffer.
    
    Rick

    
    Hi Rick,
    
    > Of course you could do a BIND/SORT to get the dataset...
    > ...- but performance may suffer.
    
    When I wrote the example in .1, I knew this is the case. For �100
    records, it's acceptable, for �5000 records you'll have to wait a
    little while...
    
    Ciao,
    	
    	Simon
    
    

    Of course, you could migrate your data to Rdb, and use SRA, which can
    sort on any field (including on any indexes you want to define -- Rdb
    lets you define as many ascending and descending indexes as you need on
    a table).  You could also develop a view of just the distinct values
    you want to use, or have a trigger-maintained table built, or...

    Joe Duncan @ OPA