Base Mysql données modifiée non vues sur client

Bonjour,
Je n'ai pas trouvé la réponse à mon problème sur le forum alors je pose ici la question.
J'ai un serveur avec une base mysql accessible via internet.
J'ai un site web qui se connecte à la base et aussi des applications lourdes via un connecteur mysql odbc 32 bits.
Mon problème est le suivant, lorsque des données sont modifiées en base, mes clients lourds qui ont déjà requété les données, ne voient pas les modifications...
Un redémarrage de l'application résout le problème.
Je suis loin d'être un expert mysql... j'ai cherché s'il y avait un cache au niveau du connecteur sans succès. Quelqu'un peut me dire où je dois chercher, il doit bien y avoir un paramètre qui gère cela quelque part!
Merci,
Thierry

Salut tedd71.

Comment gérez-vous les transactions dans vos applications ?

Qu'avez-vous mis pour ce paramètre "transaction-isolation" dans le fichier My.Ini ?

@+

Citation:

---

Envoyé par tedd71

Bonjour,
Je n'ai pas trouvé la réponse à mon problème sur le forum alors je pose ici la question.
J'ai un serveur avec une base mysql accessible via internet.
J'ai un site web qui se connecte à la base et aussi des applications lourdes via un connecteur mysql odbc 32 bits.
Mon problème est le suivant, lorsque des données sont modifiées en base, mes clients lourds qui ont déjà requété les données, ne voient pas les modifications...
Un redémarrage de l'application résout le problème.
Je suis loin d'être un expert mysql... j'ai cherché s'il y avait un cache au niveau du connecteur sans succès. Quelqu'un peut me dire où je dois chercher, il doit bien y avoir un paramètre qui gère cela quelque part!
Merci,
Thierry

---

Un SGBDR ne met pas à jour les vues des clients de manière automatique. Ce n'est pas son rôle sinon il passerait sa vie à scruter toutes les secondes et renvoyer toutes les données de tous les clients et le système s'écroulerait sous la charge… Dans un système client serveur c'est le client qui demande, pas le serveur qui fourgue sa camelote d'autorité…. Imagine un peu que se cela donnerait si, au restaurant, le serveur venait te voir à la table en te fourguant un nouveau plat toutes les secondes sur la table pour que tu le manges !!!!!!

C'est donc à tes clients de rafraichir leurs données et cela peut se faire de différentes manières combinables :
1) manuellement par un bouton sur lequel l'utilisateur doit appuyer
2) automatiquement lors d'un événement (modif faite pas l'utilisateur dans l'écran par exemple)
3) via un timer qui demande un rafraichissement au SGBDR de manière régulière, par exemple toutes les 20 secondes (mais par principe je suis contre ce genre de façon de faire qui va écrouler la montée charge…)

A +

Hello,

Effectivement, attention aux méthodes de polling (PULL) automatiques. C'est parfait pour faire s'écrouler un SGBDR, surtout quand c'est fait de façon triviale.

En mode auto, il y a moyen de faire théoriquement mieux avec du PUSH. C'est le serveur qui prévient le client que les données ont changé.
Bien entendu, ce n'est pas gratuit, mais c'est déjà mieux.
Ca peut être implémenté au niveau de la base, du driver, des deux, de façon plus ou moins native.

Par exemple:

• PostgreSQL listen/modify
• Oracle Continuous Query Notifications
• SQL Server Query Notifications

Have fun

Pour information, cette technique dite de "call back" était implémentée il y a fort longtemps sur les bases paradox via Delphi !!!!

A +

He oui !


Delphi, du temps de Borland, jusqu'à Delphi 7, que de bons souvenirs.
J'avais oublié les joies du BDE. Merci.

Have fun