Utilisation des transactions avec le BDE

De RAD Studio
Aller à : navigation, rechercher

Remonter à Utilisation des transactions avec le BDE - 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.

Par défaut, le BDE fournit un contrôle de transaction implicite pour vos applications. Quand une application est sous contrôle de transaction implicite, une transaction distincte est utilisée pour chaque enregistrement d'un ensemble de données écrit dans la base de données sous-jacente. Les transactions implicites garantissent à la fois un minimum de conflits de mise à jour des enregistrements et une vue cohérente de la base de données. En revanche, comme chaque ligne de données écrite dans une base de données prend place dans sa propre transaction, le contrôle de transaction implicite peut conduire à un trafic réseau excessif et réduire les performances de l’application. De plus, le contrôle de transaction implicite ne protège pas les opérations logiques qui recouvrent plusieurs enregistrements.

Si vous contrôlez explicitement les transactions, vous pouvez choisir le meilleur moment pour lancer, valider ou annuler vos transactions. Quand vous développez des applications en environnement multi-utilisateur, surtout quand elles fonctionnent sur un serveur SQL distant, il vaut mieux contrôler les transactions explicitement.

Il existe deux façons, mutuellement exclusives de contrôler les transactions explicitement dans une application de base de données BDE :

  • Utiliser le composant base de données pour contrôler les transactions. Le principal avantage de l’emploi des méthodes et des propriétés d’un composant base de données est que cela fournit une application propre, portable, qui ne dépend pas d’une base de données ou d’un serveur particulier. Ce type de contrôle de transaction est supporté par tous les composants de connexion aux bases de données et est décrit dans Gestion des transactions.
  • Utilisez le SQL transparent dans un composant requête pour passer des instructions SQL directement aux serveurs distants SQL ou ODBC. Le principal avantage du SQL transparent est que vous pouvez utiliser les capacités de gestion avancée des transactions d’un serveur de base de données particulier, comme la mise en cache de schéma. Pour comprendre les avantages du modèle de gestion de transaction de votre serveur, voir la documentation de votre serveur de base de données.

Quand vous travaillez sur des bases de données locales, vous pouvez utiliser seulement le composant base de données pour créer des transactions explicites (les bases de données locales ne supportent pas le SQL transparent). Cependant, il existe des limitations à l’emploi des transactions locales. Pour de plus amples informations sur l'utilisation des transactions locales, voir Utilisation de transactions locales.

Remarque : Vous pouvez minimiser le nombre des transactions nécessaires en mettant les mises à jour en mémoire cache. Pour de plus amples informations sur les mises à jour en mémoire cache, voir Utilisation d'un ensemble de données client pour mettre en cache les mises à jour.

Voir aussi