|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| J'en ai rêvé... Windev pourrait le faire... |
| Débuté par Rida HAKIM, 05 déc. 2005 11:54 - 29 réponses |
| |
| | | |
|
| |
Posté le 05 décembre 2005 - 11:54 |
Depuis que HyperFile existe en client/serveur, une instruction pourrait 'révolutionner' la façon de développer des applications avec affichage d'informations en temps réel.
En effet, jusqu'à maintenant, pour mettre à jour un affichage , il n'existait pas de solution miracle : il fallait effectuer un 'Timersys' pour actualiser l'écran, sachant qu'un délai trop long signifie un temps réel... pas vraiment réel, et un délai trop court des flux d'informations continus et importants si l'information consiste en une table.
Mais avec l'avènement du Client/Serveur, on peut passer d'une techonologie 'Pull' ou on va chercher l'information, à une techonologie 'Push', ou l'information nous est automatiquement envoyée. Pour ce faire, Windev devra proposer une instruction qui réalise un abonnement à un fichier. Cet abonnement permettra de recevoir automatiquement un mesage dès que le serveur HyperFile aura détecté que les conditions de l'abonnement ont été remplies. A l'application ensuite d'aller chercher l'information.
Une telle instruction pourrait être par exemple :
hevenement(NomdeFichier,NomdeProcedure,Portée,<NumeroEnreg>,<NomRubrique>,)
- Nom de Fichier : nom du fichier sur lequel porte l'abonnement
- Nom de Procedure : nom de la procedure appellée à chaque réception de message
- Portée : portée de l'abonnement : tout le fichier ou uniquement un enregistrement donné. Dans ce cas, NuméroEnreg doit être renseigné.
- Si NumeroEnreg a été précisé, la portée de l'abonnement se limite à l'enregistrement ayant le NuméroEnreg.
- Si NomRubrique est précisé, l'abonnement concerne alors uniquement la rubrique en question, et non toutes les rubriques du fichier.
NomProcedure aura pour parametre :
NomProcedure(NomdeFichier,NumeroEnreg,NomRubrique,TypeModification)
TypeModification peut avoir les trois valeurs suivantes :
- Modification : le fichier, l'enregistrement ou la rubrique a changée
- Suppression : le contenu du fichier ou l'enregistrement a été supprimé.
- Création : un enregistrement a été crée
Les possibilités et les applications d'un telle instruction sont illimitées.
Qu'en pensez-vous? Le débat est ouvert.
Rida HAKIM
Dakar |
| |
| |
| | | |
|
| | |
| |
Posté le 05 décembre 2005 - 14:44 |
Oui, c'est un idée interessante mais ne penses tu pas que le serveur passera
plus de temps à contacter les clients qu'à traiter les données, j'imaginerai
plus une requête permettant de connaitre les enregistrements modifiés ou
ajoutés depuis la dernière fois, un simple champ DateHeure suffirait pour
connaitre ces enregistrements
"Rida HAKIM" <rhakim@arc.sn> a écrit dans le message de news:
439415fe$1@news.pcsoft.fr...
Depuis que HyperFile existe en client/serveur, une instruction pourrait
'révolutionner' la façon de développer des applications avec affichage
d'informations en temps réel.
En effet, jusqu'à maintenant, pour mettre à jour un affichage , il
n'existait pas de solution miracle : il fallait effectuer un 'Timersys'
pour actualiser l'écran, sachant qu'un délai trop long signifie un temps
réel... pas vraiment réel, et un délai trop court des flux d'informations
continus et importants si l'information consiste en une table.
Mais avec l'avènement du Client/Serveur, on peut passer d'une techonologie
'Pull' ou on va chercher l'information, à une techonologie 'Push', ou
l'information nous est automatiquement envoyée. Pour ce faire, Windev
devra proposer une instruction qui réalise un abonnement à un fichier. Cet
abonnement permettra de recevoir automatiquement un mesage dès que le
serveur HyperFile aura détecté que les conditions de l'abonnement ont été
remplies. A l'application ensuite d'aller chercher l'information.
Une telle instruction pourrait être par exemple :
hevenement(NomdeFichier,NomdeProcedure,Portée,<NumeroEnreg>,<NomRubrique>,)
- Nom de Fichier : nom du fichier sur lequel porte l'abonnement
- Nom de Procedure : nom de la procedure appellée à chaque réception de
message
- Portée : portée de l'abonnement : tout le fichier ou uniquement un
enregistrement donné. Dans ce cas, NuméroEnreg doit être renseigné.
- Si NumeroEnreg a été précisé, la portée de l'abonnement se limite à
l'enregistrement ayant le NuméroEnreg.
- Si NomRubrique est précisé, l'abonnement concerne alors uniquement la
rubrique en question, et non toutes les rubriques du fichier.
NomProcedure aura pour parametre :
NomProcedure(NomdeFichier,NumeroEnreg,NomRubrique,TypeModification)
TypeModification peut avoir les trois valeurs suivantes :
- Modification : le fichier, l'enregistrement ou la rubrique a changée
- Suppression : le contenu du fichier ou l'enregistrement a été supprimé.
- Création : un enregistrement a été crée
Les possibilités et les applications d'un telle instruction sont
illimitées.
Qu'en pensez-vous? Le débat est ouvert.
Rida HAKIM
Dakar
|
| |
| |
| | | |
|
| | |
| |
Posté le 05 décembre 2005 - 16:07 |
Oui, c'est un idée interessante mais ne penses tu pas que le serveur passera
plus de temps à contacter les clients qu'à traiter les données, j'imaginerai
plus une requête permettant de connaitre les enregistrements modifiés ou
ajoutés depuis la dernière fois, un simple champ DateHeure suffirait pour
connaitre ces enregistrements
N'oublions pas une chose : cette instruction est sensé remplacer une commande 'Timersys' qui va continuellement lire un fichier. Actuellement, avec un Timersys, le serveur va traiter et envoyer les données toutes les n centièmes, secondes, minutes ou heures (suivant la valeur du timer). Ce que je suggère va au contraire alléger le travail du Serveur puisque l'instruction est supposée remplacer les 'Timersys' gros consommateurs de ressources réseaux. Tout ce que le serveur va faire, c'est envoyer un petit message pour avertir de la modification, alors qu'il aura envoyé un gros paquet de données en temps normal. A charge au client ensuite de lire les informations modifiées qui peuvent être aussi bien juste un enregistrement que tout le client
Il est clair que le travail 'économisé' par le serveur sera perdu à consulter la table des abonnements pour voir s'il faut avertir le client à chaque maj. Même si, dans le pire des cas, le temps de réaction du serveur reste le même, on aura alors quand même réussi le pari : avoir du temps réel 'réel' et sans efforts du poste client.
Rida |
| |
| |
| | | |
|
| | |
| |
Posté le 05 décembre 2005 - 18:22 |
Désolé mais je n'y vois aucun interet 
Si j'ai bien compris nous avons un serveur A qui est alimenté en temps réel par une application backoffice. Tout les X secondes parametrées pour chaque client B, C... les données touchées (insérées, modifiées, supprimées) depuis le dernier envoi sont envoyées sous forme d'alerte.
Pour moi ce que vous décrivez est ni plus ni moins qu'une réplication entre le serveur A (maitres) et vos clients (esclaves) sans flux de données.
Auriez-vous un cas concret de mise en application ? |
| |
| |
| | | |
|
| | |
| |
Posté le 05 décembre 2005 - 19:30 |
Cela est complètement différent de la réplication : la base de donnée n'a pas besoin d'être repliquée, car cela signifie qu'il faut envoyer en permanence des données entre le serveur et TOUTES les bases replica. Dans le cas de la nouvelle instruction, la base n'existe que sur le serveur.
Deux exemples :
Dans une application que j'ai eu à développer, une dizaine de vendeurs établissent des factures, puis les valident pour qu'elles apparaissent à la caisse. La caisse à son tour, une fois le montant encaissé, imprime la facture. La caisse doit en permanence scanner le fichier des factures pour afficher uniquement les factures validées. Ce scan est exécuté en permanence toutes les 5 secondes. Il peut y avoir parfois un délai de plusieurs minutes sans mise-a-jour de la rubrique "Validée" des enregistrements du fichier facture. Un évènement sur la rubrique en question permetrait de recevoir un message à chaque fois qu'une des factures a été validée. Ce qui permet trois choses : éviter de scanner inutilement à intervalle régulière le fichier des factures, avoir une info en temps réel qu'une facture a été validée, et avoir immédiatement le numéro de l'enreg de la facture modifiée, ce qui évite également de scanner toutes les factures validées.
Dans une application de serveur de fax, une dizaine d'utilisateurs enregistrent dans un fichier les informations du fichier fax à envoyer.
Du côté du serveur de fax, une telle instruction permet d'éviter de scanner en permanence les demandes de fax pour connaitre ceux qui n'ont pas été envoyés. Il suffit de recevoir à chaque fois par message le numéro du nouvel enregistrement à faxer.
Du côté du client fax, à chaque demande d'envoi de fax, un abonnement à cet enregistrement permet de récupérer en temps réel chaque changement d'état du fax enregistré dans le fichier par le serveur de fax : fax occupé, erroné, envoyé... Sachant qu'un même client peut avoir plusieurs demandes, chaque demande aura son propre abonnement.
Dans une application de gestion de stock, un abonnement à la rubrique "Stock" d'un produit permet d'afficher en temps réel le stock du produit.
Concrètement, à chaque fois qu'un fichier est en permanence manipulé par plusieurs utilisateurs, et que ce fichier est lu en permanence quelque part, cette instruction est plus que salutaire.
Prenez une des applications que vous avez développé : si elle contient une instruction Timersys qui lit un ou plusieurs enregistrements, cette nouvelle commande peut la remplacer de façon plus efficace. Bien sûr, le Timersys le fait très bien, mais cette commande le ferait beaucoup mieux. Et le mieux, c'est bien connu, est l'ennemi du ... 
Toujours pas d'accord?
Rida |
| |
| |
| | | |
|
| | |
| |
Posté le 05 décembre 2005 - 22:55 |
Il se trouve que Rida HAKIM a formulé :
Cela est complètement différent de la réplication : la base de donnée n'a pas besoin d'être repliquée, car cela signifie qu'il faut envoyer en permanence des données entre le serveur et TOUTES les bases replica. Dans le cas de la nouvelle instruction, la base n'existe que sur le serveur. Deux exemples : Dans une application que j'ai eu à développer, une dizaine de vendeurs établissent des factures, puis les valident pour qu'elles apparaissent à la caisse. La caisse à son tour, une fois le montant encaissé, imprime la facture. La caisse doit en permanence scanner le fichier des factures pour afficher uniquement les factures validées. Ce scan est exécuté en permanence toutes les 5 secondes. Il peut y avoir parfois un délai de plusieurs minutes sans mise-a-jour de la rubrique "Validée" des enregistrements du fichier facture. Un évènement sur la rubrique en question permetrait de recevoir un message à chaque fois qu'une des factures a été validée. Ce qui permet trois choses : éviter de scanner inutilement à intervalle régulière le fichier des factures, avoir une info en temps réel qu'une facture a été validée, et avoir immédiatement le numéro de l'enreg de la facture modifiée, ce qui évite également de scanner toutes les factures validées. Dans une application de serveur de fax, une dizaine d'utilisateurs enregistrent dans un fichier les informations du fichier fax à envoyer. Du côté du serveur de fax, une telle instruction permet d'éviter de scanner en permanence les demandes de fax pour connaitre ceux qui n'ont pas été envoyés. Il suffit de recevoir à chaque fois par message le numéro du nouvel enregistrement à faxer. Du côté du client fax, à chaque demande d'envoi de fax, un abonnement à cet enregistrement permet de récupérer en temps réel chaque changement d'état du fax enregistré dans le fichier par le serveur de fax : fax occupé, erroné, envoyé... Sachant qu'un même client peut avoir plusieurs demandes, chaque demande aura son propre abonnement. Dans une application de gestion de stock, un abonnement à la rubrique "Stock" d'un produit permet d'afficher en temps réel le stock du produit. Concrètement, à chaque fois qu'un fichier est en permanence manipulé par plusieurs utilisateurs, et que ce fichier est lu en permanence quelque part, cette instruction est plus que salutaire. Prenez une des applications que vous avez développé : si elle contient une instruction Timersys qui lit un ou plusieurs enregistrements, cette nouvelle commande peut la remplacer de façon plus efficace. Bien sûr, le Timersys le fait très bien, mais cette commande le ferait beaucoup mieux. Et le mieux, c'est bien connu, est l'ennemi du ... Toujours pas d'accord? Rida
Je comprends bien le principe. J'ai countourné le problème en utilisant
un trigger. A chaque modification du fichier, une icone apparaissait
dans la barre de message. Dès que l'icone changeait, je rafraichissais
ma table. Le timer ne faisait alors qu'une chose et c'est très rapide,
c'est vérifier l'état de l'icone. Si elle change, il enclenche à juste
titre le rafraichissement de ma table.
Ton idée est pas mal, mais imagine que tu travailles uniquement sur des
requêtes et pas sur les fichiers natifs...ils faudraient qu'elles se
réexécutent automatiquement au moment de la modification du fichier
natif, et si il y en 10 en cours...pfff pas évident et de toutes
manières on retombe sur un système de trigger et/ou de timer.
A+
--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net |
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 08:48 |
Bonjour,
Au contraire, ce serait très intéresant. Il y a des tas de cas ou l'on
aurait besoin d'avoir en temps réel les modifs sur un fichier afin de
réafficher les infos à jour !
Pascal
"Emmanuel Lecoester" <elecoest@netcourrier.com> a écrit dans le message de
news: 439470f8@news.pcsoft.fr...
Désolé mais je n'y vois aucun interet Si j'ai bien compris nous avons un serveur A qui est alimenté en temps réel par une application backoffice. Tout les X secondes parametrées pour chaque client B, C... les données touchées (insérées, modifiées, supprimées) depuis le dernier envoi sont envoyées sous forme d'alerte. Pour moi ce que vous décrivez est ni plus ni moins qu'une réplication entre le serveur A (maitres) et vos clients (esclaves) sans flux de données. Auriez-vous un cas concret de mise en application ? |
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 09:53 |
Cela est complètement différent de la réplication : la base de donnée n'a pas besoin d'être repliquée, car cela signifie qu'il faut envoyer en permanence des données entre le serveur et TOUTES les bases replica. Dans le cas de la nouvelle instruction, la base n'existe que sur le serveur.
Deux exemples :
Dans une application que j'ai eu à développer, une dizaine de vendeurs établissent des factures, puis les valident pour qu'elles apparaissent à la caisse. La caisse à son tour, une fois le montant encaissé, imprime la facture. La caisse doit en permanence scanner le fichier des factures pour afficher uniquement les factures validées. Ce scan est exécuté en permanence toutes les 5 secondes. Il peut y avoir parfois un délai de plusieurs minutes sans mise-a-jour de la rubrique "Validée" des enregistrements du fichier facture. Un évènement sur la rubrique en question permetrait de recevoir un message à chaque fois qu'une des factures a été validée. Ce qui permet trois choses : éviter de scanner inutilement à intervalle régulière le fichier des factures, avoir une info en temps réel qu'une facture a été validée, et avoir immédiatement le numéro de l'enreg de la facture modifiée, ce qui évite également de scanner toutes les factures validées.
Dans une application de serveur de fax, une dizaine d'utilisateurs enregistrent dans un fichier les informations du fichier fax à envoyer.
Du côté du serveur de fax, une telle instruction permet d'éviter de scanner en permanence les demandes de fax pour connaitre ceux qui n'ont pas été envoyés. Il suffit de recevoir à chaque fois par message le numéro du nouvel enregistrement à faxer.
Du côté du client fax, à chaque demande d'envoi de fax, un abonnement à cet enregistrement permet de récupérer en temps réel chaque changement d'état du fax enregistré dans le fichier par le serveur de fax : fax occupé, erroné, envoyé... Sachant qu'un même client peut avoir plusieurs demandes, chaque demande aura son propre abonnement.
Dans une application de gestion de stock, un abonnement à la rubrique "Stock" d'un produit permet d'afficher en temps réel le stock du produit.
Concrètement, à chaque fois qu'un fichier est en permanence manipulé par plusieurs utilisateurs, et que ce fichier est lu en permanence quelque part, cette instruction est plus que salutaire.
Prenez une des applications que vous avez développé : si elle contient une instruction Timersys qui lit un ou plusieurs enregistrements, cette nouvelle commande peut la remplacer de façon plus efficace. Bien sûr, le Timersys le fait très bien, mais cette commande le ferait beaucoup mieux. Et le mieux, c'est bien connu, est l'ennemi du ...
Toujours pas d'accord?
Rida |
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 10:07 |
Le trigger ne marche que pour les modifs de fichier faites sur le poste ou le trigger a été programmé, mais quid des dizaines d'autres postes en réseau qui accèdent en même temps au fichier? Leurs modifs ne seront pas visible en temps réel.
Concernant le problème des requêtes, cela ne change pas : la réception du message n'exécute pas le réaffichage, mais indique que le fichier ou l'enregistrement a été changé. C'est au programmeur de faire ensuite le traitement qui l'intéresse. Mais pour éviter l'overload, il suffirait au moment de la réception du message, s'il Faut réafficher (car cette instruction peut aussi servir à juste tester l'état d'un enregistrement), de désactiver l'abonnement et de le réactiver en sortie de affichage. Entre temps, pas d'abonnement, dont pas de réception de message, donc pas de risque de 'surchauffe'.
Rida |
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 11:32 |
Bonjour,
j'ai pas testé en C/S mais est-ce que la fonction hVersion ne pourrait pas vous aider.
Avant le premier affichage de votre table, vous mémorisez la valeur de hVersion (voir l'aide en ligne) puis à intervalle (avec timersys), vous vérifiez la valeur retournée par hVersion par rapport à celle que vous aviez mémorisée.
Si la valeur à changé c'est que le contenu du fichier à changé.
Vous pouvez donc effectuer le rafraichissement que s'il est nécessaire.
Si vous utilisez des requêtes, le principe est le même.
Vous mémorisez le ou les hVersion des fichiers concernés par la requête et vous n'actualisez celle-ci que si nécessaire. |
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 12:06 |
Bonjour,
je réponds en début car le message est long.
L'idée proposée est intéressante, mais est tout de même très simple à
faire sans la gestion d'un évènement venant du serveur.
Vous faites, une table spécifique évènement qui sera complétée en
fonction des besoins.
Le plus simple est que le client fasse la lecture de
ce qu'il a besoin, si le serveur envoie quelque chose c'est le
résultat. Imaginer si le serveur envoie X message à 100 clients voire
plus sachant que l'information ne sert qu'à un seul! chaque client va
devoir traiter X messages sachant qu'il n'en a rien à faire, il est
préférable que le client fasse dans un thread une requête et décide de
l'action à mener.
Un truc qui manque sur pas mal de SGBDR c'est l'envoi d'un évènement
pour maintenance du serveur au client
"Rida HAKIM" <rhakim@arc.sn> writes:
Cela est complètement différent de la réplication : la base de donnée n'a pas besoin d'être repliquée, car cela signifie qu'il faut envoyer en permanence des données entre le serveur et TOUTES les bases replica. Dans le cas de la nouvelle instruction, la base n'existe que sur le serveur. Deux exemples : Dans une application que j'ai eu à développer, une dizaine de vendeurs établissent des factures, puis les valident pour qu'elles apparaissent à la caisse. La caisse à son tour, une fois le montant encaissé, imprime la facture. La caisse doit en permanence scanner le fichier des factures pour afficher uniquement les factures validées. Ce scan est exécuté en permanence toutes les 5 secondes. Il peut y avoir parfois un délai de plusieurs minutes sans mise-a-jour de la rubrique "Validée" des enregistrements du fichier facture. Un évènement sur la rubrique en question permetrait de recevoir un message à chaque fois qu'une des factures a été validée. Ce qui permet trois choses : éviter de scanner inutilement à intervalle régulière le fichier des factures, avoir une info en temps réel qu'une facture a été validée, et avoir immédiatement le numéro de l'enreg de la facture modifiée, ce qui évite également de scanner toutes les factures validées. Dans une application de serveur de fax, une dizaine d'utilisateurs enregistrent dans un fichier les informations du fichier fax à envoyer. Du côté du serveur de fax, une telle instruction permet d'éviter de scanner en permanence les demandes de fax pour connaitre ceux qui n'ont pas été envoyés. Il suffit de recevoir à chaque fois par message le numéro du nouvel enregistrement à faxer. Du côté du client fax, à chaque demande d'envoi de fax, un abonnement à cet enregistrement permet de récupérer en temps réel chaque changement d'état du fax enregistré dans le fichier par le serveur de fax : fax occupé, erroné, envoyé... Sachant qu'un même client peut avoir plusieurs demandes, chaque demande aura son propre abonnement. Dans une application de gestion de stock, un abonnement à la rubrique "Stock" d'un produit permet d'afficher en temps réel le stock du produit. Concrètement, à chaque fois qu'un fichier est en permanence manipulé par plusieurs utilisateurs, et que ce fichier est lu en permanence quelque part, cette instruction est plus que salutaire. Prenez une des applications que vous avez développé : si elle contient une instruction Timersys qui lit un ou plusieurs enregistrements, cette nouvelle commande peut la remplacer de façon plus efficace. Bien sûr, le Timersys le fait très bien, mais cette commande le ferait beaucoup mieux. Et le mieux, c'est bien connu, est l'ennemi du ... Toujours pas d'accord? Rida
--
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
|
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 12:46 |
Bonjour,
le client serveur se distingue tout d'abord car se sont physiquement deux machine au moins une serveur et l'autre client
comment un evenement peut il intervenir sur une machine cliente sans que celle ci scan au moins l'arrivée de quelque chose (socket, fichier ou autre)
donc il faut bien en tout cas que la machine client est un timer pour arriver du signal (ne parlons pas d'evenement qui pourrait porté a confusion car les deux os ne sont pas en communication constante : l'un fait des demande , l'autre repond, mais ils ne passent pas leur temps a s'envoyer des messages)
donc la derniere solution avec le hversion est vraiement bien, on ne fait le reaffichage que si quelque chose a changer) si vous voulez que ca soit le serveur qui previenne d'un Mise a jour, il faut bien qu'il envoie quelque chose, alors que son boulot c'est de repondre a des questions)
moi je verrais bien un thread qui test le hversion et qui declenche un evenement (la c'est bon terme puisque c'est sur la meme machine) avec un postmessage .
en fin de compte vous avez tout dans windev pour pouvoir faire de dont vous revez.
un thread qui scan hversion et envoi un message
un evenement qui atten ce message et declenche votre procedure |
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 16:06 |
Concernant l'évènement : j'ai emis l'hypothèse que l'instruction peut s'appeller hevenement car contrairement à timersys, ce n'est plus Windev qui se charge de gérer le scan, mais Windows : d'ailleurs, c'est le principe de l'instruction Evenement et sEvenement : la procedure Windev n'est appellée que si l'evenement se réalise, et non pas à chaque intervale de temps. Ensuite, rien n'empêche d'intégrer cette fonction dans la DLL HF du client qui va scanner un port, un socket, ou autre chose... mais de façon totalement transparente pour l'utilisateur, exactement de la même façon que le déclenchement d'un evenement Windows est transparent.
Concernant l'instruction hVersion (qui est intéressante et que je ne connaissais pas), elle est une version light de l'instruction dont je parle. Que faire si on attend la modification d'un seul enregistrement ou d'une seule rubriquer d'un enregistrement. Je suis sûr que ce genre de test existe au moins une fois dans toutes les applications réseau. Bien sûr, on peut tout aussi bien attendre la modification de hVersion pour relire l'enregistrement et voir si la valeur attendue a changée. Mais dans ce cas, en cas de forte charge sur le fichier (grosses applications réseau ou accès très réguliers), la lecture se fera à chaque changement au lieu d'une fois dès que l'enregistrement a changé.
Finalement hVersion + thread + message = bien mais hevenement c'est beaucoup^n mieux ... 
Rida |
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 16:55 |
En toute franchise plus je lis vos réponses et moins je comprends ce que vous voulez
Pour moi désirez un mix entre un push et un pull sauf que ces deux technologies sont pour moi à l'opposé. L'une sert à pousser une information (ce qui a été modifié), l'autre a venir chercher une information (ce qui à été modifié).
Vous, vous souhaitez avoir un abonnement sur telle colonne dans telle table (sur une ligne particulière en plus ?) du coté serveur et que une modification (au sens large du terme) déclenche un flag qui sera envoyé par le serveur au client pour que ce dernier vienne chercher l'information.
Sans compter la lourdeur au niveau du serveur que celà inclus : si j'ai 10 clients avec chacun un déclencheur différent sur la même table, c'est dix traitements (ou un avec 10 actions) à faire à chaque action sur cette table.
J'ai certainement du mal comprendre votre besoin.
Emmanuel |
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 17:35 |
Bonjour,
Pour ma part, je trouve la proposition de Rida fortement intéressante,
totalement justifiée et autrement
plus "propre" (le schéma qu'elle propose sera le moins gourmand en
ressources réseau) que les autres
propositions basées sur un timer.
D'une manière générale, tous les traitements qui peuvent être fait par le
moteur de base de données
(sauf cas rares) sont plus efficaces (en terme de rapidité) que les
traitements faits par l'application
elle même.
Je me rangerai sur l'opinion de Rida et il me semble aussi qu'une telle
fonctionnalité sera bien placée
dans la "couche" hyper file de windev (une socket étant déjà ouverte entre
l'application cliente et le
serveur HF C/S).
De plus, et pour l'exemple, il est possible, lors d'un acces à sql server
via oledb de recevoir une
notification sur certains traitements liés à la table en cours de
traitement. Preuve que l'idée de Rida
est plus que bien fondée.
Et, dans tous les cas, l'argumentation de Rida est riche et fort
intéressante.
bon dev.
eric l
"Rida HAKIM" <rhakim@arc.sn> a écrit dans le message de news:
4395a270$1@news.pcsoft.fr...
Concernant l'évènement : j'ai emis l'hypothèse que l'instruction peut s'appeller hevenement car contrairement à timersys, ce n'est plus Windev qui se charge de gérer le scan, mais Windows : d'ailleurs, c'est le principe de l'instruction Evenement et sEvenement : la procedure Windev n'est appellée que si l'evenement se réalise, et non pas à chaque intervale de temps. Ensuite, rien n'empêche d'intégrer cette fonction dans la DLL HF du client qui va scanner un port, un socket, ou autre chose... mais de façon totalement transparente pour l'utilisateur, exactement de la même façon que le déclenchement d'un evenement Windows est transparent. Concernant l'instruction hVersion (qui est intéressante et que je ne connaissais pas), elle est une version light de l'instruction dont je parle. Que faire si on attend la modification d'un seul enregistrement ou d'une seule rubriquer d'un enregistrement. Je suis sûr que ce genre de test existe au moins une fois dans toutes les applications réseau. Bien sûr, on peut tout aussi bien attendre la modification de hVersion pour relire l'enregistrement et voir si la valeur attendue a changée. Mais dans ce cas, en cas de forte charge sur le fichier (grosses applications réseau ou accès très réguliers), la lecture se fera à chaque changement au lieu d'une fois dès que l'enregistrement a changé. Finalement hVersion + thread + message = bien mais hevenement c'est beaucoup^n mieux ... Rida |
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 18:34 |
"Eric L." <aze@qsd.com> writes:
Bonjour,
Pour ma part, je trouve la proposition de Rida fortement intéressante,
totalement justifiée et autrement
plus "propre" (le schéma qu'elle propose sera le moins gourmand en
ressources réseau) que les autres
propositions basées sur un timer.
Je ne pense pas.
Ce que vous dites est vrai dans le cadre d'une faible
volumétrie, et dans le cas où il y a peu de client.
Si pour diverses raisons vous avez 1000 updates/min et
que vous avez 100 postes, vous allez générer en une minute 0.1 million
de messages venant du serveur.
Dans ce cas vos clients vont passer plus de temps à analyser les
messages qu'autres choses.
Parcontre, si vous déclenchez à partir du client votre requête, c'est
que le client a besoin de l'information à ce moment et que si il
trouve une modification il va la gérer.
Dans le cas d'une appli de gestion de stock, je n'ose même pas
imaginer l'usine à gaz que celà serait sur la table article/quantité
où l'utilisateur final ne comprendrait plus rien, et ne regarderait
même plus l'indicateur (enfin celà marcherait avec 2 utilisateurs,
mais à partir de 10 users le chiffre changerait tout le temps...)
D'une manière générale, tous les traitements qui peuvent être fait par le
moteur de base de données
(sauf cas rares) sont plus efficaces (en terme de rapidité) que les
traitements faits par l'application
elle même.
C'est un fait, et il est même conseillé de le faire sur le serveur par
trigger, procédure stockée. Mais il ne faut pas confondre les roles,
un moteur de base de donnée est là pour gérer les données, mais pas
pour devenir un système d'alarme.
Je me rangerai sur l'opinion de Rida et il me semble aussi qu'une telle
fonctionnalité sera bien placée
dans la "couche" hyper file de windev (une socket étant déjà ouverte entre
l'application cliente et le
serveur HF C/S).
L'idée est intéressante mais dangereuse, car incorrectement maitrisée c'est un
moyen de mettre un serveur sur les genous.
Rien n'empêche de faire une appli sur le serveur qui fait exactement
ce que propose l'idée en utilisant les sockets, et que les applis
clientes écoutent l'appli sur le serveur.
Parcontre, si c'est pour faire un système d'alarme dans le sens
administration envoyé par le serveur celà peut être pratique.
De plus, et pour l'exemple, il est possible, lors d'un acces à sql server
via oledb de recevoir une
notification sur certains traitements liés à la table en cours de
traitement. Preuve que l'idée de Rida
est plus que bien fondée.
Quel type de notification?
Et, dans tous les cas, l'argumentation de Rida est riche et fort intéressante. bon dev. eric l "Rida HAKIM" <rhakim@arc.sn> a écrit dans le message de news: 4395a270$1@news.pcsoft.fr... Concernant l'évènement : j'ai emis l'hypothèse que l'instruction peut s'appeller hevenement car contrairement à timersys, ce n'est plus Windev qui se charge de gérer le scan, mais Windows : d'ailleurs, c'est le principe de l'instruction Evenement et sEvenement : la procedure Windev n'est appellée que si l'evenement se réalise, et non pas à chaque intervale de temps. Ensuite, rien n'empêche d'intégrer cette fonction dans la DLL HF du client qui va scanner un port, un socket, ou autre chose... mais de façon totalement transparente pour l'utilisateur, exactement de la même façon que le déclenchement d'un evenement Windows est transparent. Concernant l'instruction hVersion (qui est intéressante et que je ne connaissais pas), elle est une version light de l'instruction dont je parle. Que faire si on attend la modification d'un seul enregistrement ou d'une seule rubriquer d'un enregistrement. Je suis sûr que ce genre de test existe au moins une fois dans toutes les applications réseau. Bien sûr, on peut tout aussi bien attendre la modification de hVersion pour relire l'enregistrement et voir si la valeur attendue a changée. Mais dans ce cas, en cas de forte charge sur le fichier (grosses applications réseau ou accès très réguliers), la lecture se fera à chaque changement au lieu d'une fois dès que l'enregistrement a changé. Finalement hVersion + thread + message = bien mais hevenement c'est beaucoup^n mieux ... Rida
--
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
|
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 19:02 |
Merci Eric,
Cela fait plaisir de voir que mon idée a été parfaitement comprise, et encore plus de voir que le concept existe sous sql server (même si je ne connais pas les possibilités de ce dernier dans ce domaine).
Allez messieurs les ingenieurs-développeurs de Windev, pourquoi ne pas tenter l'aventure?
Rida
P.S. : je sais que la décision reviens forcément à quelqu'un d'autre. Si cette personne lit le fil, qu'elle me fasse savoir si l'idée est réalisable, et le degrés de complexité. |
| |
| |
| | | |
|
| | |
| |
Posté le 06 décembre 2005 - 19:27 |
De plus, et pour l'exemple, il est possible, lors d'un acces à sql server
via oledb de recevoir une
notification sur certains traitements liés à la table en cours de
traitement. Preuve que l'idée de Rida
est plus que bien fondée.
Quel type de notification?
http://msdn.microsoft.com/library/default.asp…
cette interface permet de savoir si, sur un enregistrement défini, une
modification a été faite
par un autre utilisateur (au niveau de l'enregistrement ou d'une rubrique)
sans pour autant devoir
en faire la demande régulièrement au serveur.
ca se rapproche de la proposition de Rida mais ne permet pas me semble t il
d'etre notifié
des ajouts dans la table spécifiée
eric l.
"Daniel" <voir-la-signature@wanadoo.fr> a écrit dans le message de news:
m2mzjew5f9.fsf@doudou.coul.fr...
"Eric L." <aze@qsd.com> writes: Bonjour,
Pour ma part, je trouve la proposition de Rida fortement intéressante,
totalement justifiée et autrement
plus "propre" (le schéma qu'elle propose sera le moins gourmand en
ressources réseau) que les autres
propositions basées sur un timer.
Je ne pense pas. Ce que vous dites est vrai dans le cadre d'une faible volumétrie, et dans le cas où il y a peu de client. Si pour diverses raisons vous avez 1000 updates/min et que vous avez 100 postes, vous allez générer en une minute 0.1 million de messages venant du serveur. Dans ce cas vos clients vont passer plus de temps à analyser les messages qu'autres choses. Parcontre, si vous déclenchez à partir du client votre requête, c'est que le client a besoin de l'information à ce moment et que si il trouve une modification il va la gérer. Dans le cas d'une appli de gestion de stock, je n'ose même pas imaginer l'usine à gaz que celà serait sur la table article/quantité où l'utilisateur final ne comprendrait plus rien, et ne regarderait même plus l'indicateur (enfin celà marcherait avec 2 utilisateurs, mais à partir de 10 users le chiffre changerait tout le temps...) D'une manière générale, tous les traitements qui peuvent être fait par le
moteur de base de données
(sauf cas rares) sont plus efficaces (en terme de rapidité) que les
traitements faits par l'application
elle même.
C'est un fait, et il est même conseillé de le faire sur le serveur par trigger, procédure stockée. Mais il ne faut pas confondre les roles, un moteur de base de donnée est là pour gérer les données, mais pas pour devenir un système d'alarme.
Je me rangerai sur l'opinion de Rida et il me semble aussi qu'une telle
fonctionnalité sera bien placée
dans la "couche" hyper file de windev (une socket étant déjà ouverte
entre
l'application cliente et le
serveur HF C/S).
L'idée est intéressante mais dangereuse, car incorrectement maitrisée c'est un moyen de mettre un serveur sur les genous. Rien n'empêche de faire une appli sur le serveur qui fait exactement ce que propose l'idée en utilisant les sockets, et que les applis clientes écoutent l'appli sur le serveur. Parcontre, si c'est pour faire un système d'alarme dans le sens administration envoyé par le serveur celà peut être pratique. |
| |
| |
| | | |
|
| | |
| |
Posté le 07 décembre 2005 - 10:31 |
Bonjour à tous
Excellente idée, et à la lecture de toutes les réponses, le sujet est
"brûlant".
Noubliez pas l'adage :
Quand vous avancez une idée, vous avez contre vous ceux qui auraient pensé
le contraire, ceux qui pensent comme vous et qui ne veulent pas le
reconnaître, et la très grande majorité de ceux qui n'avaient pensé à rien
du tout.
Espérant que PC Soft prendra en compte votre remarque.
Gérard
"Rida HAKIM" <rhakim@arc.sn> a écrit dans le message de news:
4395cbc1$1@news.pcsoft.fr...
Merci Eric,
Cela fait plaisir de voir que mon idée a été parfaitement comprise, et
encore plus de voir que le concept existe sous sql server (même si je ne
connais pas les possibilités de ce dernier dans ce domaine).
Allez messieurs les ingenieurs-développeurs de Windev, pourquoi ne pas
tenter l'aventure?
Rida
P.S. : je sais que la décision reviens forcément à quelqu'un d'autre. Si
cette personne lit le fil, qu'elle me fasse savoir si l'idée est
réalisable, et le degrés de complexité.
|
| |
| |
| | | |
|
| | |
| |
Posté le 07 décembre 2005 - 17:58 |
En réponse à Daniel,
Je viens de me rendre compte qu'il faut afficher tout le fil de discussion pour avoir accès à tes réponses.
Ce que vous dites est vrai dans le cadre d'une faible
volumétrie, et dans le cas où il y a peu de client.
Si pour diverses raisons vous avez 1000 updates/min et
que vous avez 100 postes, vous allez générer en une minute 0.1 million
de messages venant du serveur.
Erreur : c'est justement l'intêret de l'abonnement : sur 1000 updates/min, le serveur n'enverra de message que si les conditions suivantes sont remplies :
1 - le poste client s'est abonné au fichier modifié (ce ne sont plus les 100 postes qui sont concernés)
2 - Le fichier en question a été modifié (ce ne sont plus les 1000 updates qui sont concernés)
Ensuite : j'ai bien dit que cette instruction remplacera avantageusement un timersys qui lit un fichier.
Prenons un exemple : dans le cas des 1000 updates/min sue le MEME fichier, imaginez que les 100 postes fassent un timersys pour lire toutes les secondes ce fichier composé de 'seulement' 10 enregs, pour afficher ces 10 enregs à l'écran. Cela fait, pour le serveur, en plus de 1000 updates/min, 10x60x100 postes = 60000 enregs à lire et à envoyer aux clients toutes les minutes pour rafraichissement. Si l'enreg fait, disons 100 octets, sela fait environ 5,7 Mo envoyés par minute pour rafraichissement.
Deuxième possibilité, qui est l'utilisation de l'instruction d'abonnement : au lieu d'avoir 100 timersys sur les 100 postes, il y a 100 abonnements au fichier en question. Au niveau du serveur, ces 100 abonnements sont repris dans une table mémoire. A chaque update du fichier, le serveur scanne la liste des abonnements pour voir quel poste est à notifier. S'il trouve 1 ou n postes, il faut alors envoyer une notification aux poste concernés, notification de quelques octets seulement : idFichier, numero de l'enreg, valeur enreg et idrubrique soit au maximum une vingtaine d'octets. En une minute, le serveur aura fait 1000upd x 100 lignes de table0000 scans en MEMOIRE et envoyé 1,9 Mo aux postes.
Récapitulons.
D'un côté : 60000 lectures sur disque et 5,9 Mo envoyés sur le réseau.
De l'autre : 100000 tests en mémoire et 1,9 Mo envoyés sur le réseau.
Imaginez ce que cela donne si la taille de l'enreg est de plusieurs centaines d'octets, ou si le fichier fait plusieurs dizaines -pour ne pas dire centaines- d'enregistrements.
On peut aussi rétorquer qu'on peut avoir plus que 1000 updates/minutes pour 100 postes, soit 10 upd/min pour chaque poste, donc une maj par poste toutes les 6 secondes. A moins que des robots ne soient aux commandes des postes en question, je ne vois pas quel humain est capable de traiter des informations aussi vite (ou alors pendant un laps de temps très très court).
Bien sûr, j'ai pris le cas extrême : 100 timersys par secondes (pour 100 postes à rafraichir). Prenons le cas de 1 timersys par seconde (soit juste un poste à rafraichir)
d'un côté : 10x60`0 lectures sur disque et 10x60x100 = 59 Ko envoyés sur le réseau
de l'autre : 1000 tests en mémoire et 1000x20x1 Ko envoyés sur le réseau.
CQFD
En faisant ce simple constat, on se rend compte que dans pratiquement tous les cas de figures, on a allégé la charge sur le serveur pour une réactivité et un temps réel inégalable : Moins de rafraichissement Timersys = Plus de temps à scanner la table des abonnements = Plus de temps réel = Moins d'informations à envoyer sur le réseau = Moins de travail pour le serveur ET le client.
Rida
P.S. : je pense que ce raisonnement -qui ne découle pas vraiment d'une méthode empirique- tient la route, mais j'aimerai avoir votre avis de professionnels, et pourquoi pas me soumettre un cas (courant) ou la méthode du timersys est meilleure. |
| |
| |
| | | |
|
| | |
| |
Posté le 07 décembre 2005 - 19:08 |
Emmanuel Lecoester a formulé la demande :
En toute franchise plus je lis vos réponses et moins je comprends ce que vous voulez Pour moi désirez un mix entre un push et un pull sauf que ces deux technologies sont pour moi à l'opposé. L'une sert à pousser une information (ce qui a été modifié), l'autre a venir chercher une information (ce qui à été modifié). Vous, vous souhaitez avoir un abonnement sur telle colonne dans telle table (sur une ligne particulière en plus ?) du coté serveur et que une modification (au sens large du terme) déclenche un flag qui sera envoyé par le serveur au client pour que ce dernier vienne chercher l'information. Sans compter la lourdeur au niveau du serveur que celà inclus : si j'ai 10 clients avec chacun un déclencheur différent sur la même table, c'est dix traitements (ou un avec 10 actions) à faire à chaque action sur cette table. J'ai certainement du mal comprendre votre besoin. Emmanuel
Tout cela me semble très interressant mais je crains que le moteur de
notre base de données ne soit pénalisé par ce nouveau rôle. Déjà que
pour avoir une requête sur plus de 2 fichiers il faut se lever tôt mdr
Enfin, c'est à voir. Il faut rester "AWARE" comme dirait l'autre.
A+
--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net |
| |
| |
| | | |
|
| | |
| |
Posté le 07 décembre 2005 - 21:06 |
Bonsoir,
je suis désolé de "l'absence de sujet" mais pourtant c'est ok quand celà part. Ce soir je passe directement par le web pour ne pas reproduire le mauvais formatage du header.
Bon pour répondre à Hakim, j'ai cherché à comprendre votre argumentation, et dans le cadre d'un client/serveur je ne vois toujours aucun intéret. Maintenant, je ne comprends peut être pas complètement votre demande.
par exemple j'ai une table Appels
CREATE TABLE appels
(
ref_appel bigserial NOT NULL,
sujet char(45),
modif timestamp,
CONSTRAINT appels_pkey PRIMARY KEY (refappel)
)
sur laquelle j'ai un index sur modif.
CREATE INDEX idx_appels_idx_modif
ON appels
USING btree
(modif);
je fais un
matable_memoire.modif est une chaine qui contient les valeurs
matable_memoire.ref_appel est une chaine qui contient les valeurs
select ref_contacts,sujet,modif from appels where modif not in (matable_memoire.modif) and refappel in (matable_memoire.ref_contacts)
et ensuite je remplis ma table avec les nouvelles valeurs.
Si j'ai bien compris la seule différence que nous avons est que dans votre cas c'est le serveur qui envoie directement le résultat sans qu'on ait besoin de l'interroger.
Si je veux améliorer mon "select" je peux mettre un trigger pour créer une table temp en mémoire sur mon serveur, faire une procédure stockée pour diminuer la taille de mon message envoyé dans select ... histoire que ma requête soit la plus petite possible lorsque j'interroge mon serveur.
Donc la différence entre le mode "pull/push" est uniquement les quelques octets de la requête select en terme de réseau.
Dans votre cas vous déplacez le problème sur le serveur, vous faites celà par une notion d'abonnement, ce qui comme vous le dîtes très justement demande une table, qui doit savoir ce que vous avez comme enregistrement sur le client (il faudrait faire un truc select for update, mais sans bloquer la ligne pour que le serveur sache que le client à ces enregistrements)
Lorsque vous faites des update, vous allez par "trigger on update" créer un message qui va être diffusé au client (qui de toute façon nécessite un port ouvert sur le client probablement en multitache asynchrone).
A chaque fois que vous allez faire un update à partir d'un autre client, le serveur va déclencher une procédure, et ensuite un message.Le client qui reçoit les "évènements" va devoir traiter le message et indiquer au serveur que c'est ok, mais pendant ce temps il va recevoir le même message car il n'aura pas mis à jour ce qu'il a sur son écran etc....
Bref on part dans une boucle infernale....
Votre idée est intéressante dans le cas où on a une faible charge réseau/serveur car là effectivement si on ne sait pas quand il va y avoir une modification (dans 1 minute, 1 heure, 1 jour...) on peut attendre un message (quoique on économise uniquement la requête d'intérogation).
Finalement vous proposer du broadcoast avec le SGBDR?
Je passe le fait que dans votre cas vous envoyé x petits messages qui seront beaucoup plus volumineux en taille que 1 fois un gros messages ne serait ce que par l'encapsulation tcp...
Cordialement,
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
|
| |
| |
| | | |
|
| | |
| |
Posté le 08 décembre 2005 - 11:13 |
Bonjour Daniel,
Votre idée est intéressante dans le cas où on a une faible charge réseau/serveur car là effectivement si on ne sait pas quand il va y avoir une modification (dans 1 minute, 1 heure, 1 jour...) on peut attendre un message (quoique on économise uniquement la requête d'intérogation).
Finalement vous proposer du broadcoast avec le SGBDR?
Exactement : du broadcast.
Mais je pense que vous n'avez pas très bien compris ma démarche : cet abonnement est censé remplacer tous les Timersys qui demandent à intervalle régulier des enregistrements au serveur.
Oublions tout ce qui ce passe sur le serveur au niveau des updates du fichier : quelle que soit la méthode utilisée (Timersys ou abonnement), toutes ces modifs que font les autres clients vont et doivent être traitées, puisque c'est le principe même du développement réseau.
Concentrons nous sur le poste qui demande un Timersys. Ce poste va, à intervalles régulières, demander au serveur HF de lui envoyer un paquet d'enregistrement pour, disons, les afficher sur une table. Le serveur HF va donc, à intervalles régulières, lire les enregistrements demandés et les envoyer au client demandeur, qu'il y ait eu de modif sur ce fichier ou pas. C'est le but de l'opération : afficher les infos régulièrement pour refléter l'état du fichier à l'écran.
Maintenant imaginez une autre méthode : pas de timersys, pas de flux d'échanges permanents entre le client et le serveur à cause du timer. Voisi en gros comment cela va se passer.
1 - Le client A demande au serveur de lui envoyer le fichier X. Dès réception du fichier, il l'affiche sur la table et demande un abonnement sur ce fichier X.
2 - Aucune modification ne se fait sur ce fichier, rien ne se passe.
3 - Un autre client B modifie un enregistrement de ce même fichier X. Le serveur, après avoir traité la modification du client B (enregistrement dans le fichier, maj des index,...) va scanner la table des abonnements du fichier X (table mémoire au niveau du serveur), et va voir que le client A a demandé une notification. Il va envoyer un petit bout de message pour dire : Fichier X, enreg N modifié.
4 - Le client A reçoit le message, demande au serveur de lui envoyer l'enreg N.
5 - Le client A reçoit l'enreg N et le réaffiche : il ne réaffiche que la ligne correspondant à l'enreg N et pas la totalité de la table.
Autre cas :
1 - Le client A demande un envoi de fax à un serveur de Fax F. Il crée un enregistrement N dans un fichier FaxAEnvoyer X au niveau du serveur de fichier S.
2 - Il crée un abonnement sur cet enregistrement N, Rubrique R (étatfax).
3 - Le serveur de Fax F va lire cet enregistement et déclencher la procédure d'envoi de fax. Cette procédure va prendre du temps, et passer par diverses étapes : numérotation, synchronisation avec le fax distant, envoi du fax, et arrêt de la communication/Fax envoyé. Il peut bien sûr y avoir d'autres etats : fax occupé, numéro insdisponible.. ce qui va demander une autre tentative plus tard. A chacun fois que le serveur de fax F va passer à un nouvel état, il va enregistrer cet état dans la rubrique Etatfax de l'enregistrement demande de Fax. Le serveur de fichier S va écrire la modif sur disque, voir l'abonnement, et envoyer un message au client A pour lui notifier que le fichier X, Enregistrement N, Rubrique R a désormais la valeur V. Dans ce cas, aucune demande de lecture n'est faite : le client C a déjà l'état du fax (Rubrique R valeur V).
Encore une fois, un Timersys a été évité. Dans ce cas particulier, le gain en volumes transmit se limite à un seul enregistrement. Mais ce timersys sera exécuté chaque seconde pour avoir en temps réel l'évolution de la demande de fax. Alors que l'abonnement aura demandé 4 messages, un pour chaque modification d'état.
Je me permet d'insister car je suis sûr de l'utilité d'une telle instruction : dans la quinzaine d'applications que je manipule tous les jours il n'y en pas une qui n'en tirerai bénéfice. Et ce sont des applications très classiques dans leur conception, mais toutes en réseau : facturation, livraison, caisse, POS, serveur de fax, GED, comptabilité, ...
Rida |
| |
| |
| | | |
|
| | |
| |
Posté le 08 décembre 2005 - 14:25 |
Je passe le fait que dans votre cas vous envoyé x petits messages qui
seront beaucoup plus volumineux en taille que 1 fois un gros messages ne
serait ce que par l'encapsulation tcp...
et l'algorithme de Nagle ?
http://msdn.microsoft.com/library/default.asp…
eric l.
|
| |
| |
| | | |
|
| | |
| |
Posté le 08 décembre 2005 - 15:23 |
Bonjour,
"Eric L." <aze@qsd.com> writes:
Je passe le fait que dans votre cas vous envoyé x petits messages qui
seront beaucoup plus volumineux en taille que 1 fois un gros messages ne
serait ce que par l'encapsulation tcp...
et l'algorithme de Nagle ?
Ok, mais dans ce cas on s'éloigne de la problématique temps réel
De plus, il me semble que la RFC896 est intéressante dans le cadre
d'application type telnet, histoire de ne pas envoyer un message de 40
octets pour 1 octet d'info?
--
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
|
| |
| |
| | | |
|
| | |
| |
Posté le 14 février 2014 - 14:42 |
Bonjour,
Petit up sur cette idée, qui pour moi est un indispensable !
Un système d’événement sur la bdd est conceptuellement plus intéressant qu'un "scrutage" périodique.
A quelques barrières près on pourrait presque le faire avec un trigger serveur, mais le soucis c'est que les procédures stockées ne permettent pas de faire de la communication ( socket, ...)
Si quelqu'un à une idée je suis preneur !
Bonne continuation à vous. |
| |
| |
| | | |
|
| | |
| |
Posté le 14 février 2014 - 16:15 |
Bonjour Thierry
les fonctions h permettent maintenant d'envoyer des messages aux
clients... Il est donc tout à fait possible d'envisager d'avoir UN
process sur le serveur qui scrute la base (ou des triggers serveur) et
qui envoient un message aux clients quand nécessaire... Il faudrait
ajouter un système d'abonnement des clients, facile à faire en ajoutant
ces infos dans un fichier, et hop
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
Plus d'infor |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
102 messages
Popularité : +4 (6 votes) |
|
Posté le 15 février 2014 - 09:25 |
Si j'ai bien compris votre demande permettez moi de vous rappeler une fonction très intéressante.
Pour chaque fichier de données il existe une information qui change lors de chaque action sur le fichier "ajout, modification et suppression"
La fonction est
HVersion (Fonction)
En anglais : HVersion
Permet de savoir :•si le contenu d'un fichier de données a été modifié.
•si le contenu d'un fichier de données utilisé par une requête a été modifié.
donc seulement avec cette fonction on peut savoir s'il y a eu un changement sur le fichier ou non.
depuis l'existence de cette fonction nous l'utilisons et nous a épargné beaucoup de temps et plus d'efficacité.
Surtout n'hésiter pas à nous contacter pour toute information utile.
http://www.hrs-technologie.com
sales@hrs-technologie.com
--
HRS TECHNOLOGIE |
| |
| |
| | | |
|
| | |
| |
Posté le 10 juin 2017 - 15:15 |
12 ans après ... PC SOFT a implémenté mon idée, et habonnement est devenu hsurveille. Comme quoi l'idée n'était pas si folle 
Allez PC SOFT, un dernier petit effort, ajouter nous un hsurveilleRubrique pour surveiller juste une rubrique d'un fichier et le jeu d'instructions sera au complet
Rida HAKIM |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
948 messages
Popularité : +30 (92 votes) |
|
Posté le 11 juin 2017 - 17:19 |
Coucou,
Rida HAKIM, y a un sujet ouvert pour la version 23
https://forum.pcsoft.fr/fr-FR/pcsoft.fr.windev/206560-windev-23-envies-suggestion/read.awp
Sa pourais etre tres interesant si tu faisait un post pour cette idée dessus ^^
--
Charly CanDo.
Forg en Nouvelle-Zélande - In üs we trust
irc.freenode.net - ##pcsoft |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|