Confirmed D2 bug: cached updates don't work for master/detail - here's why

By tracing through the D2 VCL, I have uncovered a flaw in the design of cached
updates and am working on a solution to same.

The problem exists when updating tables having a master/detail relationship.  
It is necessary to update the master first, then the details (e.g. when
inserting a new tree of records), but when you do so, the detail tables are
requeried and the updates are lost.

Specifically, the flaw goes like this.  Let's assume for simplicity that the
master table is unmodified, and only the detail has updates pending:

(1)  Application calls DB.ApplyUpdates.  
(2)  DB calls the ApplyUpdates routine for the first table (master).
(3)  TDataset.ApplyUpdates calls ProcessUpdates(dbiUpdatePrepare)
(4)  In our case, nothing interesting happens until ProcessUpdates calls
Resync().
(5)  Nothing interesting happens in Resync until DataEvent(DataSetChange, 0).
(6)  However, at that time, all of the subordinate datasets are requeried!  
(You can trace right to the culprit statement if you want to but it would make
this memo much longer.)

The changes, inserts, etc. you made to the subordinate tables are now *gone.*  
The "UpdateStatus" of the table becomes dsUnmodified and no further cached
update queries are issued -- at all! -- against them.

Naturally, I am stunned and dismayed that Borland permitted the code to go out
in this condition.  I think that an hours' worth of honest-to-God testing
would have revealed this flaw, but it cost me two days.  Let's just say that I
don't think I paid $1,800 for this piece of software to _ever have this
experience, and no one else did, either.

If there's an update-fix CD-ROM that contains a solution to this problem, if
it's a known problem, then I hope one will arrive at my door and that it will
be complementary.

/mr/
(602) 946-8259; fax (602) 874-2068