Why Use Cached Updates?

I wanted to implement a table structure where the master record held a total amount for the receipt and each of the detail records contained another amount. The total of all the detail records should agree to that in the master record.

• Minimize transaction times - source Delphi Help
• Minimize network traffic - source Delphi Help
• Provide a pseudo transaction and coarse undo operation for database updates - Advantage

Why not use Cached Updates

In spite of the promise of cached updates, there are many significant problems in using them,

• Cached updates are discarded when
  • the dataset is closed
  • the master record in a master-detail relationship is changed
  • the master record is edited after making cached changes to the detail
• The complexity of cached updates causes bugs and quirks within the BDE
• During the processing of the cached updates, some may be updated, others may not. Cached updates do not provide true ACID transactions

The way that the checked updates are discarded proved difficult to code around. For example, you can catch the change of the master record by using the BeforeScroll event but cached updates are sensitive to the order of the changes. If the current master is edited after adding cached changes against the detail record, they are then lost.

So the original requirement (that of a consistent receipt) can only be achieved by using a database transaction (a unit of work).

References

• What IB Objects says about using Cached Updates and the BDE in general
• Advantage TDataSet Documentation