OK, now you get to see how little I know. I have been working on the
business intelligence side of the house (data retrieval) and/or
management since the mid-80's. Before that I was a COBOL CICS IMS
developer. So, I've never been a DataBASIC programmer. I do have
manuals and also Jon Sisk's book on BASIC, but I'm feeling lazy while
watching skating on TV (prompting the husband to head to the other room
to watch football) and most of you can answer this before the next
down.

Question: What would a BASIC statement look like that deletes a
MultiValue with a specified number or the first one with a specified
value (whichever is easiest) and does not leave a gap, but moves the
values behind it up in the list.

File: MYFILE
Record: 12345
Field: EMAIL
MultiValued
Values:
emailaddress1
emailaddress2
emailaddress3
emailaddress4

and I want to delete the second one so that the list is

emailaddress1
emailaddress3
emailaddress4

Thanks. --dawn

dawn wrote:

del rec<emailatt,emailaddrpos>

or

del<9,2>

or

rec=delete(rec,emailatt,emailaddrpos)

or

locate emailaddr in rec<emailatt>,1 setting pos then del
rec<emailatt,pos>

or ... variations ad infinitum.

dawn wrote:

del rec<emailatt,emailaddrpos>

or


del rec<9,2>


or


rec=delete(rec,emailatt,emailaddrpos)


or


locate emailaddr in rec<emailatt>,1 setting pos then del
rec<emailatt,pos>


or ... variations ad infinitum

Mike Preece wrote:
Thanks for the quick response. In this case emailatt must be the LOC
for the field EMAIL, right?

9 being the LOC for the EMAIL attribute and 2 being the MultiValue
position is what I gather, which means you first need a read of some
sort to assign the record to rec, if I am reading that correctly.

Got it. It appears that each of these first requires a separate
statement to read the record before you can use the operation that
remove the multivalue. I think that answers my question. Thanks.
--dawn

dawn wrote:

Yes. A slightly more complete example might be along these lines :-

open 'myfile' else debug
read rec from 12345 else debug
emailatt=9
emailaddrpos=2
del rec<emailatt,emailaddrpos>
write rec on 12345
end

....which is equivalent to...

open 'myfile' else debug
read rec from 12345 else debug
del rec<9,2>
write rec on 12345
end

HTH,
Mike.

Dawn,

If you are doing research for your blog, remember that if there are
other fields associated with the email (eg: email type =
bus|private|blind) then you would need to also remove these related
values in order to maintain referential integrity.

This is one of the "gotcha's" you will have with the CDT crowd. Many
tools (like Visage) will do this sort of thing automatically for you
.... in Basic this must be done by the application programmer.

UV has a rudimentary mechanism to at least indicate which multi-valued
fields are co-related via the "Association" field - even MORE
rudimentary in D3 where you have a controlling/dependent mechanism. In
all cases developers are given the "flexibility" of NOT maintaining
this information (and unfortunately this tends to be the case!! One of
the biggest strengths of the mv paradigm is its flexibilty. One of the
biggest weaknesses of the mv paradgm is its flexibility)

Ross Ferris wrote:
It is perhaps due to some unfortunate circumstance that I happen to
have known this, but would have had to verify down the road, so thanks
for the heads up.

RI, in general, is an issue for Pick with one extremely important
exception--entity/property relationships where the properties are
multivalued. Since I'm not in marketing for any MV company, I don't
have to try to claim that it is good to have all RI specified
repeatedly in applications. When I weigh the options I would prefer we
start with MV and fix such issues (which any site can do by writing
wrapper I-O routines as you have likely done in Visage).

Or by the I-O library developer, would might also be the app
programmer, the DBA, the systems analyst, the documentation writer, and
the QA team (but that's another story).

as does UniData. That was part of Prime Information.

I haven't used D3, but it is a shame they are missing the ASSOC

As Henry Eggers said, it gives the developer enough rope to hang
themselves.

Thanks a bunch! --dawn

Ross Ferris wrote:
Oh come on, Ross. The damned controlling-dependent fields are really
pretty pointless. It's probably been 25 years since I've seen the things
in use, and event then, they were pretty lame.

Luke

IIRC you need to use the d;c structures to make exploding sorts work
(BOM type stuff - oh no, wait, that's the "V" correlative on the data
portion of the file ...sheesh!)

Whilst "lame", they are better than nothing! As Dawn suggested we
'stole'/modified/extended the notion of a simple, single level
association into something that supports >100 levels of nesting, and in
her example provide a "primative" (subroutine) function that will
remove all related values & associations for, say an "emails"
association.

Whilst I appreciate that we have been given rope, it is perhaps
unfortunate that we had such a wide choice of knots and trees!
Personally I think that a little more rigour in the environment would
have been useful, even if it was by way of (yet another) option or
correlative buried into the system that COULD have been turned on.

Virtually every "4GL" that I'm aware of for multi-value has had to
devote resources to filling in these gaps ... again, and again, and
again.

Spilt milk now, and I'm all out of tears! With all of the latent
"power" of the dictionaries in the "correlative database" environment
we call multi-valued, it is perhaps unfortunate that Basic wasn't
enhanced to harness some of this power as well (D3 ended up getting
some extensions, but I think to little, to late, and no documentation)

Historically everyone has been reluctant to embark on change because of
the "installed base" - yet if you look at the changes that have been
"forced" upon developers in recent years in the Microsoft world using
VB (from say 3 through 6, and now .NET 1 & 2) we can see that people
WILL (albiet reluctantly) adopt change.

DO you have any idea how often questions about DOS 6 crop up in the
Microsft forums? Yet here we find people time warped with technology
that pre-dates this --> I mean we still use R83 as a base-line ?!?

On the one hand, it is a testimony to the underlying technology that
some of these ancient systems still run. It is also one of the most
fundamental problems our market faces, because soooo many people think
that it isn't broken, the users are conditioned to not pay "real
money", and the Database Vendors appear to have forgotten how to
evangalize & innovate & champion their products.

Hmmm,late at night, way OT and beginning to ramble .... time for a
snooze (dare I say I need a cat nap 'cause later today we start 2 new
uni-grads on their journey of discovery, and expect they will have
their first GUI, web-deployable multi-valued screens working before the
end of their first working day. Nothing like giving them a feeling of
REAL accomplishment after they have spent 4 years learning JAVA :-)

heads up on the locate syntax in UV if using the prime flavor (and
possibly other flavors):
locate val in dynarr<att,startpos> (or <att,val,starpos> for sv)

If you use dynarr<att> - is will scan each attribute (,1 is not assumed
because that is not the syntax)




Mike Preece wrote: