John,

Thanks for the response.  I on UniData.  I was thinking that perhaps this 
was the result of a UDT.OPTION setting...  Oh!  I think I've just come 
across the answer - please see below:

When performing a SELECT statement that employs the SAVING UNIQUE keyword 
against a multi-valued field - the resulting list will contain two 
valuemarks on each line with a number in between after the saved value. An 
example is useful to demonstrate:

:SELECT STUDENT.TERMS SAVING UNIQUE STTR.STUDENT.ACAD.CRED SAMPLE 100 
SAVE.LIST LIST.TEST 
:AE SAVEDLISTS LIST.TEST000 
Top of "LIST.TEST000" in "SAVEDLISTS", 345 lines, 4,093 characters. 
001: ý1ý1 
002: 1003926ý1ý1 
003: 1003927ý2ý1 
004: 1003928ý3ý1 
005: 1024941ý1ý1 
006: 1024942ý2ý1 
007: 1024943ý3ý1 
008: 1036527ý1ý1 
009: 1036528ý2ý1 
010: 1036529ý3ý1 

The resulting list above causes issues with the LIST ALGERBRA command...

These seemingly extraneous valuemarks and numbers are actually the normal 
behavior of UniData when using the SAVING UNIQUE keyword on a multi-valued 
field (which is the case with STTR.STUDENT.ACAD.CRED).

The easiest way to get rid of the value marks and numbers that are added 
to each line in the savedlist after using the SAVING UNIQUE on a 
multi-valued field is to perform a subsequent select. In this situation 
the STTR.STUDENT.ACAD.CRED field is a multi-valued pointer to the 
STUDENT.ACAD.CRED file... with an active list (from the savedlist 
conaining the valuemarks or directly after the SAVING UNIQUE query) select 
again against the STUDENT.ACAD.CRED file. This will result in the same 
list of IDs and will not contain the valuemarks or numbers as seen after 
the SAVING UNIQUE query.

Here are a couple examples that will produce the desired list in a 
savedlist record named GOOD.LIST:

If you already have the list containing the valuemarks, etc... activate 
that list and select against the STUDENT.ACAD.CRED file:
:SELECT STUDENT.TERMS SAVING UNIQUE STTR.STUDENT.ACAD.CRED SAMPLE 100
147 records selected to list 0.

>SAVE.LIST RAW.LIST
147 key(s) saved to 1 record(s).

:GET.LIST RAW.LIST
147 records retrieved to list 0.

>SELECT STUDENT.ACAD.CRED
146 records selected to list 0.

The following record ids do not exist:

>SAVE.LIST GOOD.LIST
146 key(s) saved to 1 record(s).
:

If you perform a query using the SAVING UNIQUE keyword against a 
multi-valued field, you can execute the second query immediately:
:SELECT STUDENT.TERMS SAVING UNIQUE STTR.STUDENT.ACAD.CRED SAMPLE 100
147 records selected to list 0.

>SELECT STUDENT.ACAD.CRED
146 records selected to list 0.

The following record ids do not exist:

>SAVE.LIST GOOD.LIST
146 key(s) saved to 1 record(s).
:

If the list produced from the SAVING UNIQUE query does not produce a list 
of IDs for another file... then it will be necessary to remove the extra 
value marks and numbers manually. 



From:   John Thompson <[email protected]>
To:     U2 Users List <[email protected]>
Date:   04/06/2012 08:48 AM
Subject:        Re: [U2] Unwanted Duplicated
Sent by:        [email protected]



If this is Universe I would say look for some option somewhere that is
not set.  Perhaps it behaves differently between account flavors.

For example, in a BASIC program in a PICK flavor account, in order to
use multiple SELECT lists you have to put $OPTIONS -x (I think) at the
top on the program.

Shot in the dark.

On 4/5/12, Greg Coelho <[email protected]> wrote:
> Hey Guys,
>
> I am selecting SAVING UNIQUE on a multivalue field.  I then MERGE.LIST
> these ID's with a larger group - which should itself only return Unique
> ID's.  What I am getting returned is a sizeable number of duplicates.
> Looking closer it appears that these ID's are often attached to a value
> marker which suggests that they were sitting with a Null Value that was
> pulled in with the ID.
>
> 'GET.LIST WORKING.IMOD.6 TO 1'
> 'SELECT ADDRESS WITH ADDRESS.CHANGE.DATE GE ':X.CHG.DATE:' SAVING UNIQUE
> RESIDENTS'
> 'SAVE.LIST GET.IMOD.ADDRESS'
> 'GET.LIST GET.IMOD.ADDRESS TO 2'
> 'MERGE.LIST 1 UNION 2 TO 3'
> 'SAVE.LIST WORKING.IMOD.7 FROM 3'
>
> *** WORKING.IMOD.7 is full of dups!
>
> I was thinking about trying -
>
> SELECT ADDRESS WITH ADDRESS.CHANGE.DATE GE ':X.CHG.DATE:' SAVING UNIQUE
> RESIDENTS NO.NULLS'
>
> Any recommendations?
>
> As Aways - Thanks!
>
> Greg
> _______________________________________________
> U2-Users mailing list
> [email protected]
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>

-- 
Sent from my mobile device

John Thompson
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to