Discussion :

[stephane_lec]

Bonjour,

Je travaille sur une application client / serveur sous Delphi. Le serveur possède des TDataSetProvider, et les clients des TClientDataSet.

Lorsque deux fenêtres du client affichent des données de la même table, j'utilise éventuellement deux TClientDataSet dont les données sont celles de la même table (le même provider sur le serveur). Je souhaiterais pouvoir rafraîchir les données de l'un d'eux si l'autre les modifie.

J'ai déjà mon idée pour mettre en place une structure de données permettant d'informer les différents TClientDataSet concernés qu'ils doivent se mettre à jour, mais étant donné que ce problème est d'ordre général, il existe certainement des obljets permettant de faire ceci sans développement supplémentaire.

Par extension, je souhaiterais par la suite permettre des rafraîchissement sur un client alors que les données ont été modifiées par un autre client.

Merci d'avance si vous connaissez une solution à mon problème !

[star]

Lorsque deux fenêtres du client affichent des données de la même table, j'utilise éventuellement deux TClientDataSet

Pourquoi 2 TClientDataSet ?
S'agissant d'afficher les données de la même table dans 2 fenêtres du client, des controles BD dans chacune des 2 fenêtres ayant pour DataSource une même source de données suffisent non ?
Toute modification effectuée dans les controles de l'une des 2 fenêtres entrainera automatiquement la mise à jour des controles de l'autre.

[bNoureddine]

Bonjour,

Je travaille sur une application client / serveur sous Delphi. Le serveur possède des TDataSetProvider, et les clients des TClientDataSet.

Lorsque deux fenêtres du client affichent des données de la même table, j'utilise éventuellement deux TClientDataSet dont les données sont celles de la même table (le même provider sur le serveur). Je souhaiterais pouvoir rafraîchir les données de l'un d'eux si l'autre les modifie.

J'ai déjà mon idée pour mettre en place une structure de données permettant d'informer les différents TClientDataSet concernés qu'ils doivent se mettre à jour, mais étant donné que ce problème est d'ordre général, il existe certainement des obljets permettant de faire ceci sans développement supplémentaire.


Pour le rafraichissement, il suffit de fermer et d'ouvrir la table.

Par extension, je souhaiterais par la suite permettre des rafraîchissement sur un client alors que les données ont été modifiées par un autre client.

Merci d'avance si vous connaissez une solution à mon problème !

[stephane_lec]

Pourquoi 2 TClientDataSet ?

L'intérêt d'avoir un TClientDataSet propre à une fenêtre est en particulier de rester positionné, dans un tableau par exemple, sur le même enregistrement à la réouverture de la fenêtre.
De manière générale, on est sûrs de ne pas avoir d'effets de bords, par exemple si on applique un filtre à l'un des TClientDataSet, on ne filtre pas les données d'une autre fenêtre.

[Sylvain James]

Tu peux cloner tes clientdataset.
Regarde du côté de CloneCursor...

Sylvain

[stephane_lec]

Merci bien pour le tuyau.

Il me reste par contre à gérer la synchronisation entre un DataSet basé sur une table, et un autre contenant une requête SQL qui lit les données de cette même table...

Est-ce que par hasard ceci existerait ?
Par exemple en mettant dans la requête SQL, non pas le nom de la table, mais une référence vers le DataSet ?

Et il me restera encore la synchronisation entre deux clients...

Merci.

[Sylvain James]

Il me reste par contre à gérer la synchronisation entre un DataSet basé sur une table, et un autre contenant une requête SQL qui lit les données de cette même table...

Est-ce que par hasard ceci existerait ?
Par exemple en mettant dans la requête SQL, non pas le nom de la table, mais une référence vers le DataSet ?

Et il me restera encore la synchronisation entre deux clients...

Merci.

oula on est en dehors des concepts de base là :-)
Bon si tu veux synchroniser la position courante sur les curseurs clients (les clientdataset ou dataset quelconque qui a obtenu et mémorisé des enregs suite à l'exécution de la req SQL), il faut que lorsque tu te déplaces sur le premier, tu fasses un locate sur le second.
Si tu parles de synchronisation au niveau de la modification des données, alors ça marche pas comme ça... Il faut que le dataset reéxécute la requête pour obtenir une version plus récente des enregs.
Si vraiment tu veux être informé automatiquement alors il faut mettre en place des evènements système de communication interprocess ou utiliser les fonctionnalités avancées de ton SGBD selon ses possibilités (ex. IBEvents pour Interbase). Mais attention, tout ça consomme des ressources et de la bande passante. Ca peut vite se compliquer selon le traffic.

Sylvain

[stephane_lec]

Effectivement, je parle de synchronisation des données.
En ce qui est des possibilités de mon SGBD, ça ne va pas chercher très loin car il s'agit d'Access...

Je pensais sinon récupérer au démarrage une référence vers chaque TClientDataSet, dont on redéfinirait certains événements pour être prévenu des modifications effectuées au niveau d'un objet unique à l'application.

Dans le cas d'un DataSet basé sur une table, on sait donc quelle table est modifiée, et pour une requête SQL, on peut toujours l'analyser pour le savoir.

Il faudrait donc que l'objet global soit informé des modifs et puisse à son tour informer tous les DataSet utilisant la table modifiée...

C'est faisable, mais c'est quand même pas mal de boulot. Mais apparemment, je n'ai pas d'autre solution...

[Sylvain James]

Je pensais sinon récupérer au démarrage une référence vers chaque TClientDataSet, dont on redéfinirait certains événements pour être prévenu des modifications effectuées au niveau d'un objet unique à l'application.

Dans le cas d'un DataSet basé sur une table, on sait donc quelle table est modifiée, et pour une requête SQL, on peut toujours l'analyser pour le savoir.

Il faudrait donc que l'objet global soit informé des modifs et puisse à son tour informer tous les DataSet utilisant la table modifiée...

C'est faisable, mais c'est quand même pas mal de boulot. Mais apparemment, je n'ai pas d'autre solution...

Je comprends pas tout ton schmilblick Je vois pas comment tu veux implémenter des evènements au niveau du clientdataset pour prévenir d'autres cds de ses modifications, alors qu'on ne sait même pas si ces modifs ont été appliquées au serveur ?
Ce que tu peux faire, c'est au moment où tu envoies la mise à jour au serveur, le TDataSetProvider qui va servir d'intermédiaire va recevoir ce paquet de mise à jour, alors là tu peux implémenter le gestionnaire d'évènement OnUpdateData, qui va te permettre de parcourir tous les enregs en passe d'être mis à jour (ou dans AfterUpdateRecord on passe ds cet évènement pour chaque enreg). A ce moment là, tu peux construire une liste de données que tu vas transmettre aux autres application par un moyen de communication interprocess approprié selon la configuration (même machine, sur le réseau ?, sur le web ? etc etc.). Selon l'architecture qui va te permettre de faire communiquer tes applis, c'est plus ou moins compliqué.


Sylvain

[stephane_lec]

Je pensais créer un objet dérivé de TClientDataSet sur lequel je redéfinirais différents événement afin qu'il prévienne mon objet global des modifications sur les données.

Puisque je définis ma propre classe, je n'ai pas besoin d'aller coller un peu partout des bouts de code qui vont faire ça. J'ai déjà fait un petit bout de soft qui remplace dans des sources Delphi un composant par un autre (TClientDataSet par TMonClientDataSet par exemple), ce qui réduit le boulot.

J'envisage par contre de permettre au client de fonctionner temporairement sans serveur, en cas de plantage par exemple (et oui, ça peut arriver...)
Dans ce cas, je suis obligé de traiter ça au niveau du cient, sauf évidemment la synchronisation entre les différents clients.

Je peux exploiter sur un TClientDataSet les événements AfterDelete, AfterEdit et AfterInsert (ou AfterPost) qui, réunis, doivent ressembler à un "AfterUpdateData".