Gestion des sessions de bases de données
Remonter à Gestion des sessions de bases de données - 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.
Les requêtes, curseurs, pilotes et connexions de bases de données d'une application BDE sont maintenues dans le contexte d'une ou plusieurs sessions BDE. Les sessions isolent un ensemble d'opérations d'accès à une base de données, comme les connexions de bases de données, sans qu'il soit nécessaire de lancer une autre instance de l'application.
Toutes les applications BDE comprennent automatiquement un composant session par défaut, nommé Bde.DBTables.Session, qui encapsule la session BDE par défaut. Quand les composants base de données sont ajoutés à l'application, ils sont automatiquement associés à la session par défaut (notez que son SessionName est "Default"). La session par défaut fournit un contrôle global sur tous les composants base de données non associés à une autre session, qu'ils soient implicites (créés par la session à l'exécution quand vous ouvrez un ensemble de données non associé à un composant base de données que vous avez créé) ou persistant (créé explicitement par votre application). La session par défaut n'est pas visible dans votre module de données ou votre fiche au moment de la conception, mais vous pouvez accéder par code à ses propriétés et à ses méthodes lors de l'exécution.
Pour utiliser la session par défaut, vous n'avez pas à écrire de code, à moins que votre application doive :
- Explicitement activer ou désactiver une session, en activant ou désactivant la capacité d'ouverture de base de données de la session.
- Modifier les propriétés de la session, par exemple spécifier les propriétés par défaut pour les composants base de données générés implicitement.
- Exécuter les méthodes d'une session, comme gérer les connexions aux bases de données (par exemple ouvrir et fermer des connexions de bases de données en réponse aux actions de l'utilisateur).
- Répondre aux événements de session, comme quand l'application essaie d'accéder à une table Paradox ou dBASE protégée par mot de passe.
- Définir des répertoires Paradox comme avec la propriété NetFileDir pour accéder aux tables Paradox sur un réseau et avec la propriété PrivateDir sur un disque dur local pour accélérer les performances.
- Gérer les alias BDE qui décrivent les configurations de connexion possibles pour les bases de données et les ensembles de données qui utilisent la session.
Que vous ajoutiez les composants base de données à une application au moment de la conception ou que vous les créiez dynamiquement à l'exécution, ils sont automatiquement associés à la session par défaut, à moins que vous ne les affectiez spécifiquement à une session différente. Si vous ouvrez un ensemble de données non associé à un composant base de données, Delphi va automatiquement :
- Créer un composant base de données pour cet ensemble de données à l'exécution.
- Associer le composant base de données à la session par défaut.
- Initialiser certaines propriétés-clés du composant base de données, basées sur celles de la session par défaut. Parmi les plus importantes de ces propriétés se trouve KeepConnections, qui détermine quand les connexions de bases de données sont maintenues ou interrompues par l'application.
La session par défaut procure un large ensemble de valeurs par défaut pouvant être utilisées par la plupart des applications. Il n'est nécessaire d'associer un composant base de données à une session explicitement nommée que si le composant exécute une requête simultanée sur une base de données déjà ouverte par la session par défaut. Dans ce cas, chaque requête concurrente doit fonctionner dans sa propre session. Les applications de bases de données multithreads requièrent aussi des sessions multiples, dans lesquelles chaque thread possède sa propre session.
Les applications peuvent créer des composants session supplémentaires selon leurs besoins. Les applications de bases de données BDE comprennent automatiquement un composant liste de session, nommé Bde.DBTables.Sessions, que vous pouvez utiliser pour gérer tous vos composants session. Pour plus d'informations sur la gestion de sessions multiples, voir Gestion de sessions multiples.
Vous pouvez placer sans risque des composants session dans des modules de données. Cependant, si vous mettez un module de données contenant un ou plusieurs composants session dans le référentiel d'objets, assurez-vous que la propriété AutoSessionName a pour valeur True pour éviter tout conflit d'espace d'appellation quand les utilisateurs en héritent.