Yeah, the BSELECT works, I'm using it as an alternative... I just like to ensure to remove duplicates too which is why I was using SAVING UNIQUE. I was just wondering why the value marks... And the thing is that its only when using LIST.ALGEBRA that I found a problem with this. If you just do a plain LIST on the table from the active select list you don't get this problem when using SAVING UNIQUE.
ps/ Another way to get rid of the value marks is to do the following... SELECT PERSON.ST 3152750 SAVING UNIQUE PST.ROOM.ASSIGNMENTS SELECT ROOM.ASSIGNMENTS * this removes the extra data SAVE.LIST X.1 fascinating stuff... Thanks for all the feedback, Phil On Tue, 2004-08-24 at 09:03, David L. Rotman wrote: > I believe the SAVING UNIQUE operating on a multivalued field > treats the request as a BY.EXP request...thus giving you the > value marks. > > You might want to try BSELECT to get just the individual keys: > SELECT PERSON.ST 3152749 > BSELECT PERSON.ST PST.ROOM.ASSIGNMENTS > SAVE.LIST X.1 > > > > >>> [EMAIL PROTECTED] 8/23/2004 3:26:54 PM >>> > Hi all, > > Not a regular here but I was hoping someone could enlighten me with > this > interesting 'feature' of UNIDATA... > > If I issue a select statement using saving unique on a mv field of > pointers, then edit the SAVEDLISTS file to check the IDs, I see > something like this... > > SELECT PERSON.ST 3152749 SAVING UNIQUE PST.ROOM.ASSIGNMENTS > SAVE.LIST X.1 > > AE SAVEDLISTS X.1000 > > 001: 8654y1y1 > 002: 9490y2y1 > 003: 9491y3y1 > > (where 'y' is the value marker) > > Why is there y1y1, y2y1, y3y1 appended at the end of each ID? I'm > guessing it has to do with the saving unique feature or something? > > To continue with the issue... > > SELECT PERSON.ST 3152750 SAVING UNIQUE PST.ROOM.ASSIGNMENTS > SAVE.LIST X.2 > > 001: 1443y1y1 > 002: 2904y2y1 > 003: 5128y3y1 > 004: 6743y4y1 > > > LIST.ALGEBRA X.3 = X.1 + X.2 > > the system returns: > > SIZE OF X.1 IS 3 > SIZE OF X.2 IS 4 > SIZE OF X.3 IS 7 > > result is stored in 'X.3' > > GET.LIST X.3 > 21 records retrieved to list 0. > >LIST ROOM.ASSIGNMENTS > 1443 > 2904 > 5128 > 6743 > 4 > 8654 > 9490 > 9491 > 8 records listed > Enter <CR> to print non exist record ids > 1 > 1 > 2 > 1 > 3 > 1 > 1 > 1 > 1 > 2 > 1 > 3 > > The LIST.ALGEBRA isn't ignoring what comes after the IDs and creates a > savedlists with every value delimited by the value marker. I was > expecting a total of 7 records (as indicated by LIST.ALGEBRA), when I > do > the GET.LIST X.3 there are 21 records. > > So first, what is the extraneous information at the end of each ID in > the SAVEDLISTS? If I use a BSELECT instead I do not get this extra > info. > > I am merely seeking more information with this whole thing... I was > unaware that 'extra' information is stored when doing a SAVING UNIQUE > and that using savedlists created with SAVING UNIQUE within > LIST.ALGEBRA > causes problems... or am I doing something wrong? I haven't found any > documentation that denotes the above mentionned issue. > > Thanks for any feedback, > Phil -- Philippe Parent - [EMAIL PROTECTED] Programmer Analyst, Administrative Information Services (ITS) University of New Brunswick PO Box 4400, Fredericton, NB, Canada, E3B 5A3 Phone (506) 453 3563 - Fax (506) 453 3590 ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
