Hi,
I use a DP database to control my current work: helping engineers
write articles of their work for publication in journals.
Because articles usually come to me in groups of two or more, I
used to have a two-panel scheme: GroupsOfArticles and Articles.
However, that was not sufficient because some articles are
subdivided in parts, each with its own price, deadline, etc. So
now there are three basic panels: GroupsOfArticles, Articles, and
PartsOfArticles.
In order to control invoices and payments, we must add the prices
of parts to have the price of each article, and add the prices of
articles to have the price of each group, and charge the
customer. So this involves two keep-a-totals.
Ralph Alvy discusses the keep-a-total feature in a similar
(though not identical) three-panel structure. However, he says
this about cascaded keep-a-totals, which he calls piggybacking:
In earlier versions of DataPerfect, I found piggybacking
Keep A Total operations unreliable. This may not be the case
with recent versions of DataPerfect. I haven't tested it for
a long time. I have, however, heard users complaining that,
in some of their applications, it didn't update the higher
panels, even with DataPerfect 2.3. I suggest you refrain from
piggybacking Keep A Total operations, opting to always place
a Keep A Total code in the lowest possible panel, even if
that means placing multiple Keep A Total codes on a single
field. In general, I consider this rule to ease the strain on
a relational database.
My feeling is that it would be logically easier to have a
keep-a-total from PartsOfArticles to Articles, and then another
one from Articles to GroupsOfArticles -- but that would be
cascading or piggybacking.
So, I would like to know whether Ralph's advice above still is in
force.
The reason why I am logically more comfortable with the
piggybacking scheme is the following.
Let's just call the panels A, B and C respectively.
Panel A has an ID field, and child panel B has a corresponding
field to link it to A.
Likewise, panel B has its own ID field, and panel C has a
corresponding field to link it with B.
To avoid piggybacking, there should also be a field in panel C
corresponding to the ID field of panel A in order to have a link
from C to A to allow a direct (non-piggybacking) keep-a-total.
Let's call "A1", "A2", etc. the ID values of different records in
panel A.
If records are created downwards via the F5 key, we would start
from, say, record A7, and create in panel B a child record. The
value "A7" gets automatically copied to the appropriate field of
panel B. Following that, from that record in panel B we create a
record in panel C, and the same value "A7" gets automatically
copied to the appropriate field in panel C.
So far so good.
However, it sometimes happens that I must edit that record in B
which is a child of record A7, and make it a child of some other
record, say A4. (This kind of change probably is never necessary
in databases similar to Ralph Alvy's example, but it can happen
in mine.)
That part of the operation is straightforward. However, after the
record in B had a field changed to "A4", its the respective child
records in panel C must be adjusted accordingly, i.e., "A7" must
be changed into "A4".
That can of course be done by cascade update, but two questions
occur to me here.
1. In such a scheme we do avoid piggybacking keep-a-totals, but
we have to add a cascade update. Is it really a better option
to have the cascade update instead of the piggybacked
keep-a-totals?
2. When that record in panel B changes from being a child of
record A7 to a child of record A4, do the two keep-a-total
mechanisms adjust all involved totals as appropriate?
Thanks,
Marcos
--------------------------------------
Marcos Fávero Florence de Barros
Campinas, Brazil
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/cgi-bin/mailman/listinfo/dataperf
