Hello,
I have a program on unidata 6.1 that does this (simplified):
UDTEXECUTE SELECT FILE1 SAVING UNIQUE MIGHT.BE.MULTIVALUED TO 1
UDTEXECUTE SELECT FILE2 SAVING UNIQUE MIGHT.BE.MULTIVALUED TO 2
MERGE-LIST 1 INTERSECTION 2
And it works.
However, if the dictionary item MIGHT.BE.MULTIVALUED
How do I fix this?
My program wrote items with @AM in the key. (oops)
Now, I can 'select' the items, but I cannot get rid of them - they show as
non-existent.
Is there a way to remove/clean up these records, or will I have to clear the
file and copy the good records back in?
---
u2-users
You could fix this by selecting all records EXCEPT those with keys
containing @AM in the key, copying them to a temporary file, and then
clearing the permanent file and copying from the temporary file back in.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
I open the file in a program, then use an internal select and loop readnext
Eg
Open 'file' to handle else...
Select handle
Loop
readnext key else exit
if index(key,@fm,1) then delete handle,key
Repeat
This simply moves a pointer thru the file and doesn't attempt a value
judgement of the
Trying to remember what I used to do in Universe to get rid of these
Try having a select list of these records active, then going into the
editor, and see if it will let you edit each record, and do an FD.
HTH
Drew
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Hi David,
My program wrote items with @AM in the key. (oops)
Now, I can 'select' the items, but I cannot get rid of them - they show as
non-existent.
Is there a way to remove/clean up these records, or will I have to clear
the
file and copy the good records back in?
The problem is that
uh, write the same program to construct the keys and delete them?
There are notes about finding these actual keys (to use in your fix
program) in one of my various UniData troubleshooting presentations - from
U2U, at least.
In the context of 'duplicate keys'.
I believe that the problem is that the hash algorithm used to determine which
group the item goes into uses the whole key as provided to it, but everything
after the first attribute mark becomes part of the item, and from the point of
view of the system, stops being part of the key. So a key
Bill,
Thanks for replying. Yes, the value-position suggestion makes sense, the
values in the second multivalue do appear to relate to the original MV'd
position of that list item.
I've found a more efficient work-around - to do the original selection
to list 0, READNEXTing all the IDs to a
If you are on UniVerse try setting the ALLOWMARKS flag in uvconfig, run
uvregen, restart UniVerse and then programmatically delete them (if you
generated the keys, hopefully you can recreate them),
Otherwise - (as others have advised) SELECT and copy what you want, blat the
file (CLEAR-FILE) and
Edward:
Glad everything worked out for you. One of the major problems that occurs with
lists
and dynamic arrays is arrays get very (and I mean very) inefficient when they
get
large (several thousand values). If this won't happen to you then building up a
dynamic array is fine.
In a test I
11 matches
Mail list logo
