On pourrait modéliser une dataset a l’aide d’un tableau, ainsi a la suite d’un select sur une table
On pourrait se retrouver avec l’exemple suivant en mémoire :

Un post envoie les modifications (insertion, modification, suppression) du record courant dans le cache. La
dataset ne sachant référencer qu’un seul record a la fois, toutes les méthodes de déplacement (next, prior,
last..)lancent un post implicite. L’un des intérêts des caches est donc de faire plusieurs modifications en mémoire
sans les envoyer systématiquement à la base.

Si par exemple on modifie B en Bnew, on insere DA après D, on efface C et que l’on est en train d’insérer F (on
ne l’a pas encore posté), on se retrouve avec le schéma suivant :

Un cancel travail sur l’enregistrement courant et l’annule simplement :

Un applyUpdates envoie dans la base les modifications, mais garde la dataset intacte (toutefois, si le record
courant n’a pas été posté au moment du applyUpdates, il est posté par défaut) :

Un commit envoie les modifications ‘sur le disque’ tandis que le rollBack les annule, mais pour les caches en
mémoire, ces deux opérations n’ont aucune incidence, ce qui permet de récupérer les données lors d’une erreur
(par exemple un contrôle d’intégrité) :

C’est le commitUpdates qu’il faut appeler pour mettre a jour la dataSet en mémoire, si la transaction a bien
fonctionné :

Tandis que le cancelUpdates permet de retrouver l’état initiale (lors d’une erreur au commit par exemple) :

• - La méthode post des Tdatasets en mode cachedUpdates fonctionne toujours (les contrôles sont effectués au
  moment du passage dans la base par le applyUpdates). On ne peut donc pas se fier au state de la dataset
  seule, qui passe a dsBrowse lorsque le post réussi.
• - Bien que le applyUpdates lance un post par défaut, que le cancelUpdates lance un cancel par défaut, la
  property updatesPendings ne tient pas compte d’un éventuel enregistrement qui n’aurait pas encore été
  posté. Si donc on l’utilise dans un test (par exemple pour voir si l’utilisateur a fait des modifications, il faut
  également tester l’état de la dataset.
• -A l’intérieur des procédures branchées sur les évènnements OnUpdateRecord et OnUpdateError,
  attention à ne pas confondre value, newValue. En effet, si l’événnement est lancé pour chaque
  enregistrement de la dataset, seuls NewValue et OldValue pointent sur l’enregistrement qui est en
  train d’être posté, tandis que value (et ses dérivés : asString, asVariant…) pointent sur
  l’enregistrement courant de la dataset au moment du post :