Remonter à Fichier - Index
Utilisez l'expert Nouvel objet Module de données distant pour créer un module de données accessible à distance en tant que serveur Automation à double interface. Un module de données distant réside sur le serveur d'applications, entre le client et le serveur, dans un environnement de bases de données multi-niveaux.
| Elément
|
Description
|
|
Nom de coClasse
|
Entrez le nom de base de l'interface Automation de votre module de données distant. Le nom de classe de votre module de données distant (un descendant de TRemoteDataModule) sera identique mais précédé de la lettre T. Il implémentera une interface utilisant ce nom de base mais précédé de la lettre I. Pour permettre à une application client d'accéder à cette interface, définissez la propriété ServerName du composant connexion de l'application client par le nom de base spécifié ici.
|
|
Instanciation
|
Utilisez cette boîte à options pour indiquer comment lancer l'application module de données distant. Le tableau suivant énumère les valeurs possibles :
| Valeur
|
Signification
|
|
Interne
|
Le module de données distant est créé dans un serveur en processus. Choisissez cette option lorsque vous créez un module de données distant en tant que partie d'une bibliothèque active (DLL).
|
|
Instance unique
|
Une seule instance du module de données distant est créée pour chaque exécutable. Chaque connexion client lance sa propre instance de l'exécutable. L'instance du module de données distant est donc dédiée à un seul client.
|
|
Instance multiple
|
Une seule instance de l'application (processus) instancie tous les modules de données distants créés pour les clients. Chaque module de données distant est dédié à une seule connexion client, mais ils partagent tous le même espace de processus.
|
|
|
Modèle de thread
|
Utilisez cette boîte à options pour indiquer comment les appels des clients seront passés à l'interface de votre module de données distant. Le tableau suivant énumère les valeurs possibles :
| Valeur
|
Signification
|
|
Unique
|
Le module de données reçoit seulement une demande client à la fois. Comme les demandes client sont toutes sérialisées par COM, vous n'avez pas à vous occuper des questions de threads.
|
|
Apartment
|
Chaque instance de votre module de données distant sert une demande à la fois. Mais, la DLL peut gérer plusieurs demandes à la fois sur des threads distincts si elle crée plusieurs objets COM. Les données des instances sont sécurisées, mais vous devez vous prémunir contre les conflits de threads en mémoire globale. C'est le modèle recommandé pour les ensembles de données BDE. Lorsque vous utilisez des ensembles de données BDE, vous devez ajouter un composant session avec AutoSessionName défini par True.
|
|
Libre
|
Les instances de votre module de données distant peuvent recevoir des demandes client simultanées sur plusieurs threads. Vous devez protéger les données des instances ainsi que la mémoire globale contre les conflits de threads. C'est le modèle recommandé pour les ensembles de données ADO.
|
|
Les deux
|
Comme Libre, sauf que tous les callbacks aux interfaces client sont sérialisés.
|
|
Neutre
|
Plusieurs clients peuvent appeler le module de données distant sur différents threads en même temps, mais COM garantit qu'il n'y a pas deux appels en conflits. Vous devez vous protéger des conflits de threads concernant des données globales et des données d'instance accessibles par les méthodes de plusieurs interfaces. Ce modèle est disponible uniquement sous COM+. Sinon, il est remplacé par le modèle Apartment.
|
|
|
Description
|
Entrez le texte qui apparaît dans le registre à côté de ProgID pour l'interface serveur d'application. Ce texte sert également de chaîne d'aide pour l'interface dans la bibliothèque de types.
|
|
Générer le code de support d'événement
|
Cochez cette case pour indiquer à l'expert d'implémenter une interface distincte pour la gestion des événements.
|
Voir aussi