Hi Marcos, I have cascaded Keep A Totals for years, and as far as I know I have never had a problem. You have to of course be sure that there is an unambiguous target record for the Keep-A-Total, otherwise it will create one for you - which itself can be a very handy thing. Providing the database structure is correct, then I do not think it is unreliable. Actually I have had some quite tortuous cascading Keep-A-Totals, including from memory one where there was recursion for consolidation of related groups of companies, and I think it worked to quite a substantial depth. It certainly needed to work for 3 or 4 levels of recursion.
Regards Brian -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Marcos Favero Florence de Barros Sent: Wednesday, 21 May 2014 1:41 PM To: DataPerfect Users Discussion Group Subject: [Dataperf] Cascading keep-a-totals 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 _______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/cgi-bin/mailman/listinfo/dataperf
