Hi Bill,
What are the advantages of defining in the data dictionary mv
associations?
The dictionary should be the reference model of the data. In many years of
mv consultancy, I have encountered many sites where the dictionary contains
references only to fields used in queries, leaving others undefined and pure
guesswork. This is a maintenance nightmare. Defining the associations
ensures that (a) the query processor can correctly pair up items that should
be related on a value by value basis and (b) developers can see what fields
have this relationship.
Does it mean that if I change or insert via a UniBasic writev command,
that
all of the associated fields get a null character if the program does not
explictly specify a change?
No. Programs do not automatically use the dictionary. It is used only by the
query processor unless you force some other use. My personal preference is
to mechanically generate a Basic include record of field tokens from the
dictionary (see the GENERATE command of OpenQM).
It is the programmer's responsibility to maintain the correct relationship
between associated fields. For an association with only a couple of fields,
this is not too much of a pain. For bigger associations, it is a good idea
to write a pair of subroutines to add a value or remove a value. If used
properly, this is ensures that it is impossible for a program to
accidentally miss an element of the update and destroy your data.
As a related point, you cite use of WRITEV. Never use WRITEV if you intend
to update multiple fields. Internally, WRITEV reads the record, changes the
field, and then writes the record. Doing this for more than a single field
is bad practice as it reads the record twice, albeit from the cache.
Are there any downsides to just defining a vanilla "M" field that is used
with other associated M fields.
Not sure what you mean here. Associations need to be properly paired up. If
an order record contains, for example, a pair of fields for part number and
quantity and a separate pair of fields for payment value and payment date,
this needs two separate associations if the reports are to come out
correctly.
In general, you can get away with defining all fields as multivalued (after
all, a single value is just a special case of a multivalue) but it is much
clearer to the person doing maintenance if you use these values correctly.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
