Re: [U2] UNIDATA - SAVING UNIQUE and LIST.ALGEBRA
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/ Dave Rotman Director of Computer Services Cedarville University 251 N. Main Street Cedarville, OH 45314 [EMAIL PROTECTED] voice 937-766-7905 fax 937-766-8819 --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UNIDATA - SAVING UNIQUE and LIST.ALGEBRA
it looks like PST.ROOM.ASSIGNMENT is multivalued and used for other things other then just storing the room# ??? what does the dict PST.ROOM.ASSIGNMENTS look like ? is it defining the entire attribute ? if you just want the 1'st value, create a dict item defining it and select saving unique new dict item This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UNIDATA - SAVING UNIQUE and LIST.ALGEBRA
Date: 23 Aug 2004 16:26:54 -0300 From: Philippe Parent [EMAIL PROTECTED] ... (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? ... So first, what is the extraneous information at the end of each ID in the SAVEDLISTS? ... The extra data is the attribute and value marks where the values were extracted. You can easily eliminate them by doing an EDIT-LIST (AE) and use the commands BD9/^253 followed by a C9/^253// If the data you're collecting are record IDs in a file, you can also select that file to get rid of the extra data. I suppose there's a good reason to keep the source info, but I wish there was a UDT.OPTION to turn it off... --Tom Pellitieri Century Equipment Toledo, OH --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UNIDATA - SAVING UNIQUE and LIST.ALGEBRA
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/
RE: [U2] UNIDATA - SAVING UNIQUE and LIST.ALGEBRA
I love learning new things! I had never thought that MV ID were treated this way by a savedlists. I can duplicate Philippe's results as he is using a common UniData application. PST.ROOM.ASSIGNMENTS is a MV field. SELECT PERSON.ST '0044560' SELECT PERSON.ST SAVING UNIQUE PST.ROOM.ASSIGNMENTS SAVE.LIST DWM.TEMP AE SAVEDLISTS DWM.TEMP000 001: 1606}2}1 002: 31}1}1 003: 3604}3}1 As Tom said doing a selection on the file the secondary IDs point to will strip the extra values. GET.LIST DWM.TEMP SELECT ROOM.ASSIGNMENT SAVE.LIST DWM.TEMP AE SAVEDLISTS DWM.TEMP 001: 1606 002: 31 003: 3604 Two more things I learned A: SELECT PERSON.ST '0044560' BY.EXP PST.ROOM.ASSIGNMENTS SAVE.LIST DWM.TEMP AE SAVEDLISTS DWM.TEMP000 001: 0044560}2}1 002: 0044560}1}1 003: 0044560}3}1 B: SELECT PERSON.ST '0044560' BY.EXP PST.ROOM.ASSIGNMENTS LIST ROOM.ASSIGNMENT Gives an error message, Unable to find dictionary item for 35 SELECT PERSON.ST '0044560' BY.EXP PST.ROOM.ASSIGNMENTS So, where does the savedlist store the information that the records stored in the list are associated with the field PST.ROOM.ASSIGNMENTS? David Morelli, UIS/Datatel Team -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 5:55 AM To: [EMAIL PROTECTED] Subject: Re: [U2] UNIDATA - SAVING UNIQUE and LIST.ALGEBRA Date: 23 Aug 2004 16:26:54 -0300 From: Philippe Parent [EMAIL PROTECTED] ... (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? ... So first, what is the extraneous information at the end of each ID in the SAVEDLISTS? ... The extra data is the attribute and value marks where the values were extracted. You can easily eliminate them by doing an EDIT-LIST (AE) and use the commands BD9/^253 followed by a C9/^253// If the data you're collecting are record IDs in a file, you can also select that file to get rid of the extra data. I suppose there's a good reason to keep the source info, but I wish there was a UDT.OPTION to turn it off... --Tom Pellitieri Century Equipment Toledo, OH --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UNIDATA - SAVING UNIQUE and LIST.ALGEBRA
Disregard if this doesn't answer the pertinent question. To save all unique pointers to ROOM.ASSIGNMENT from PST.ROOM.ASSIGNMENTS: SELECT PERSON.ST BY.EXP PST.ROOM.ASSIGNMENTS SELECT PERSON.ST REQUIRE.SELECT SAVING UNIQUE PST.ROOM.ASSIGNMENTS SAVE.LIST UNIQUE.ROOM.ASSIGNMENT.IDS This should produce a SAVEDLISTS record with one ROOM.ASSIGNMENT.ID per attribute. -Original Message- From: Philippe Parent [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 9:48 AM To: [EMAIL PROTECTED] Subject: RE: [U2] UNIDATA - SAVING UNIQUE and LIST.ALGEBRA I checked the dict and AE'd a few records and it only contains ROOM.ASSIGNMENT IDs. The saving unique seems to be placing the extra info... Phil --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UNIDATA - SAVING UNIQUE and LIST.ALGEBRA
Check out the documentation for READNEXT its the same feature in universe... least it looks it to me. At 03:26 PM 8/23/2004, you wrote: 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/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
