Je développe une application en Delphi qui attaque une base SQL Server
Express 2005. Cette application est composée de plusieurs modules qui
doivent être informés des modifications sur certaines tables. Exemple,
si le module A supprime une ligne d'une table ou change une valeur dans
une colonne, tous les clients connectés doivent en être informés (ou
tout au moins, savoir qu'un changement a eu lieu).
Pour la l'instant, la solution que je vois est de créer un serveur COM
qui s'occuperait de la gestion centralisée des données. Et ce serveur
enverrait des infos sur les modifs à tous les clients.
Mais peut-être qu'il existe une solution directement à partir de SQL
Server et que je pourrais récupérer cet notification de changement
directement dans mon appli.
A votre avis, il y a une possibilité plus simple que COM ?
J-L
--
J-L M. (Alphomega)
ICQ: 149635116
Pour m'écrire, cliquer le lien ci-dessous
http://cerbermail.com/?G5iYdBb2Ce
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
SQLpro
On 21 fév, 10:29, Jean-Luc M. wrote:
Bonjour,
Je développe une application en Delphi qui attaque une base SQL Server Express 2005. Cette application est composée de plusieurs modules qui doivent être informés des modifications sur certaines tables. Exemple, si le module A supprime une ligne d'une table ou change une valeur dans une colonne, tous les clients connectés doivent en être informés (ou tout au moins, savoir qu'un changement a eu lieu).
Pour la l'instant, la solution que je vois est de créer un serveur COM qui s'occuperait de la gestion centralisée des données. Et ce serveur enverrait des infos sur les modifs à tous les clients.
Mais peut-être qu'il existe une solution directement à partir de SQL Server et que je pourrais récupérer cet notification de changement directement dans mon appli.
A votre avis, il y a une possibilité plus simple que COM ?
J-L
-- J-L M. (Alphomega) ICQ: 149635116 Pour m'écrire, cliquer le lien ci-dessoushttp://cerbermail.com/?G5iYdBb 2Ce
ce n'est absolument pas une façon intelligente de faire fonctionner un SGBDRF C/S. SI vous désirez cet effet ce n'est pas avec un SGBDR C/S qu'il faut travailler, ou alors il faut inverser votre logique et travailler en verouillage préventif. Dans tous les cas les performances de votre SGBDR seront particulièrement catastrophiques. J'ai l'impression que vous aimeriez reproduire le comportement des bases Paradox de Borland qui permettaient de faire du "Call back" et donc de prevenir l'utilisateur que le jeu de données sur lequel il travaillait avait été modifié. Il n'est pas sain de vouloir reproduire un tel comportement avec un SGBDR C/S dont l'intérêt est la montée en charge car vous allez générer un traffic monstrueux capable de paraliser vos applications. Imaginez simplement que vous arriviez à produire un tel comportement sachant qu'un SGBDR comme SQL Server traite courrament 1000 connexions simultanées ... A raison d'une modif par utilisateur toute les 20 secondes, cela ferait un taffic de ... 50000 requêtes par seconde... Je vous laisse imaginer comment vous allez mettre à genou votre système.
Je pense qu'il existe d'autres moyen pour satisfaire votre problème que d'informer tous les clients.
A +
-- Frédéric Brouard - - MVP SQL Server Expert langage SQL, modélisation de données et MS SQL Server Le site du SQL : http://sqlpro.developpez.com/ Formations, conseils, audit, modélisation, optimisation, tuning : http://www.datasapiens.com
On 21 fév, 10:29, Jean-Luc M. <nos...@nospam.com> wrote:
Bonjour,
Je développe une application en Delphi qui attaque une base SQL Server
Express 2005. Cette application est composée de plusieurs modules qui
doivent être informés des modifications sur certaines tables. Exemple,
si le module A supprime une ligne d'une table ou change une valeur dans
une colonne, tous les clients connectés doivent en être informés (ou
tout au moins, savoir qu'un changement a eu lieu).
Pour la l'instant, la solution que je vois est de créer un serveur COM
qui s'occuperait de la gestion centralisée des données. Et ce serveur
enverrait des infos sur les modifs à tous les clients.
Mais peut-être qu'il existe une solution directement à partir de SQL
Server et que je pourrais récupérer cet notification de changement
directement dans mon appli.
A votre avis, il y a une possibilité plus simple que COM ?
J-L
--
J-L M. (Alphomega)
ICQ: 149635116
Pour m'écrire, cliquer le lien ci-dessoushttp://cerbermail.com/?G5iYdBb 2Ce
ce n'est absolument pas une façon intelligente de faire fonctionner un
SGBDRF C/S. SI vous désirez cet effet ce n'est pas avec un SGBDR C/S
qu'il faut travailler, ou alors il faut inverser votre logique et
travailler en verouillage préventif. Dans tous les cas les
performances de votre SGBDR seront particulièrement catastrophiques.
J'ai l'impression que vous aimeriez reproduire le comportement des
bases Paradox de Borland qui permettaient de faire du "Call back" et
donc de prevenir l'utilisateur que le jeu de données sur lequel il
travaillait avait été modifié.
Il n'est pas sain de vouloir reproduire un tel comportement avec un
SGBDR C/S dont l'intérêt est la montée en charge car vous allez
générer un traffic monstrueux capable de paraliser vos applications.
Imaginez simplement que vous arriviez à produire un tel comportement
sachant qu'un SGBDR comme SQL Server traite courrament 1000 connexions
simultanées ... A raison d'une modif par utilisateur toute les 20
secondes, cela ferait un taffic de ... 50000 requêtes par seconde...
Je vous laisse imaginer comment vous allez mettre à genou votre
système.
Je pense qu'il existe d'autres moyen pour satisfaire votre problème
que d'informer tous les clients.
A +
--
Frédéric Brouard - brouardf@club-internet.fr - MVP SQL Server
Expert langage SQL, modélisation de données et MS SQL Server
Le site du SQL : http://sqlpro.developpez.com/
Formations, conseils, audit, modélisation,
optimisation, tuning : http://www.datasapiens.com
Je développe une application en Delphi qui attaque une base SQL Server Express 2005. Cette application est composée de plusieurs modules qui doivent être informés des modifications sur certaines tables. Exemple, si le module A supprime une ligne d'une table ou change une valeur dans une colonne, tous les clients connectés doivent en être informés (ou tout au moins, savoir qu'un changement a eu lieu).
Pour la l'instant, la solution que je vois est de créer un serveur COM qui s'occuperait de la gestion centralisée des données. Et ce serveur enverrait des infos sur les modifs à tous les clients.
Mais peut-être qu'il existe une solution directement à partir de SQL Server et que je pourrais récupérer cet notification de changement directement dans mon appli.
A votre avis, il y a une possibilité plus simple que COM ?
J-L
-- J-L M. (Alphomega) ICQ: 149635116 Pour m'écrire, cliquer le lien ci-dessoushttp://cerbermail.com/?G5iYdBb 2Ce
ce n'est absolument pas une façon intelligente de faire fonctionner un SGBDRF C/S. SI vous désirez cet effet ce n'est pas avec un SGBDR C/S qu'il faut travailler, ou alors il faut inverser votre logique et travailler en verouillage préventif. Dans tous les cas les performances de votre SGBDR seront particulièrement catastrophiques. J'ai l'impression que vous aimeriez reproduire le comportement des bases Paradox de Borland qui permettaient de faire du "Call back" et donc de prevenir l'utilisateur que le jeu de données sur lequel il travaillait avait été modifié. Il n'est pas sain de vouloir reproduire un tel comportement avec un SGBDR C/S dont l'intérêt est la montée en charge car vous allez générer un traffic monstrueux capable de paraliser vos applications. Imaginez simplement que vous arriviez à produire un tel comportement sachant qu'un SGBDR comme SQL Server traite courrament 1000 connexions simultanées ... A raison d'une modif par utilisateur toute les 20 secondes, cela ferait un taffic de ... 50000 requêtes par seconde... Je vous laisse imaginer comment vous allez mettre à genou votre système.
Je pense qu'il existe d'autres moyen pour satisfaire votre problème que d'informer tous les clients.
A +
-- Frédéric Brouard - - MVP SQL Server Expert langage SQL, modélisation de données et MS SQL Server Le site du SQL : http://sqlpro.developpez.com/ Formations, conseils, audit, modélisation, optimisation, tuning : http://www.datasapiens.com
