Application des mises à jour en mémoire cache avec les méthodes de composant base de données
Remonter à Utilisation du BDE pour placer en mémoire cache les mises à jour - Index
Remarque : Le moteur de base de données Borland (BDE, Borland Database Engine) a été déprécié. Il ne sera donc pas amélioré. Par exemple, le BDE ne prendra jamais en charge Unicode. Vous ne devriez pas entreprendre de nouveaux développements avec BDE. Prévoyez plutôt de migrer vos applications de bases de données existantes de BDE vers dbExpress.
Vous pouvez appliquer directement les mises à jour d'ensembles de données BDE individuels en utilisant les méthodes ApplyUpdates et CommitUpdates de l'ensemble de données. Chacune de ces méthodes encapsule une phase du processus de mise à jour :
- ApplyUpdates écrit les mises à jour en mémoire cache dans une base de données (phase 1).
- CommitUpdates efface le cache interne quand l'écriture dans la base de données est réussie (phase 2).
Le code suivant illustre la manière d'appliquer les mises à jour dans une transaction pour l'ensemble de données CustomerQuery :
procedure TForm1.ApplyButtonClick(Sender: TObject) begin Database1.StartTransaction; try if not (Database1.IsSQLBased) and not (Database1.TransIsolation = tiDirtyRead) then Database1.TransIsolation := tiDirtyRead; CustomerQuery.ApplyUpdates; { essaie d'écrire les mises à jour dans la base de données } Database1.Commit; { en cas de réussite, les modifications sont validées } except Database1.Rollback; { en cas d'échec, les modifications sont annulées } raise; { déclenche l'exception de nouveau pour éviter un appel à CommitUpdates } end; CustomerQuery.CommitUpdates; { si succès, effacer le cache interne } end;
void __fastcall TForm1::ApplyButtonClick(TObject *Sender) { Database1->StartTransaction(); try { if (!Database1->IsSQLBased && Database1->TransIsolation != tiDirtyRead) Database1->TransIsolation = tiDirtyRead; CustomerQuery->ApplyUpdates(); // essaie d'écrire les mises à jour dans la base de données Database1->Commit(); // en cas de réussite, les modifications sont validées } catch (...) { Database1->Rollback(); // en cas d'échec, les modifications sont annulées throw; // déclenche l'exception pour empêcher un appel à CommitUpdates! } CustomerQuery->CommitUpdates(); //en cas de réussite, efface le cache interne }
Si une exception est déclenchée durant l'appel de ApplyUpdates, la transaction de base de données est annulée. Cette annulation garantit que la table de base de données sous-jacente n'est pas modifiée. L'instruction raise dans le bloc try...except redéclenche l'exception, ce qui empêche l'appel de CommitUpdates. Comme CommitUpdates n'est pas appelée, le cache interne des mises à jour n'est pas vidé, ce qui vous laisse la possibilité de gérer les conditions d'erreur et de relancer la mise à jour.