[threads]Rafraichissement des données dans une application C#/winform/SGBD

Bonjour à tous,

Suite à de longues recherches infructueuses et avant de m'avouer définitivement vaincu, j'aimerais avoir l'avis de la communauté :

Le cahier des charges :
Un poste client contenant un dataset qui correspond au chargement d'une table du sgbd distant, mais cette table ayant été modifiée entre temps par un autre client de l'application, la version du dataset en mémoire sur le poste client n'est plus à jour.

Dans la mesure ou une connexion au sgbd peut etre lente, l'objectif est de récupérer les données (requete sql sur le sgbd) via un thread distinct du thread du formulaire du poste client pour ne pas bloquer l'interface client inutilement.

Je sais qu'il existe des threads background worker fait spécifiquement pour ca, mais mon objectif est d'essayer d'utiliser des fonctionnalités de plus bas niveau en termes de threading et d'isolation des données pour des raisons de portabilités vers d'autres langages et d'évolutivité en général. Et aussi pour savoir le faire :zoubi:.

Le problème est assez simple, j'en ai conscience mais je n'ai pas réussi. Est ce que certains d'entres vous pourraient me donner leur avis et me conseiller une méthode simple et élégante pour récupérer les données sans risque d'accès concurrents sur le dataset entre le thread ui et le thread récupérant les données d'une part, puis pour la mise à jour du thread ui d'autre part, une fois les données récupérées.

Par ailleurs si certains d'entres vous sont formés sur ce point quelles sont les pratiques recommandées pour ce type de mise à jour.

Merci beaucoup à vous,
Vincent.

Bonjour à tous,

Je sais bien que ce n'est pas si simple mais si quelqu'un avait une piste de bonne qualité ou le nom d'un bon livre qui traite de ce point, il me rendrait un fier service.

Bon week-end à tous,
Vincent

Tu as des contraintes particulières ; tout le monde ne s'amuse pas à traverser le pays en mobylette quand on aune Ferrari dans le garage (dit-il en exagérant un poil :mrgreen:) Et de nombreux autres langages ont aussi des constructions de haut niveau qui évitent de faire trop de plomberie dans la gestion des threads.

Ceci dit, Backgroundworker ou pas : ça dépend. Si ton dataset est bindé (à une datagridview, à tout hasard), tu ne peux pas simplement le MAJ depuis le thread métier, puisque le binding dataset - datagridview se fait par des events levés à chaque modif.
Ce que tu peux faire, c'est simplement suspendre le binding avant la MAJ, et le remettre une fois que c'est fini. Sinon, plutôt que MAJ le dataset bindé à l'UI lui-même, tu peux faie en sorte que le thread métier renvoie un nouveau dataset; une fois le thread métier terminé, le thread d'UI prend ce dataset, suspend le binding, MAJ l'ancien dataset avec le nouveau, et remettre le binding.

Citation:

---

Un poste client contenant un dataset qui correspond au chargement d'une table du sgbd distant, mais cette table ayant été modifiée entre temps par un autre client de l'application, la version du dataset en mémoire sur le poste client n'est plus à jour.

---

Quelle est la contrainte véritable sachant qu'il sera impossible que la table soit systèmatiquement à jour ?
Il restera toujours des cas ou il y aura une différence et des conflits d'accès concurrrentiel.

Veux-tu simplement une table à peu près à jour ?

Dans ce cas, pour répondre à l'objectif consistant à actualiser le dataset dès qu'une modif est détectée sur le SGBD, on peut insérer un champ d'horodatage automatique en cas de modification/création et interroger périodiquement la table par une requête portant sur ce champ afin d'exraire les derniers ajouts/créations (solution alternaticve pour SQL server : SQLDependency). Toutefois, cette approche consomme des ressources CPU, réseau et SGBD et ne règle pas le problème des suppressions ...

Bonjour à tous et plus particulièrement à Guulh et Graffito,

Je viens d'aller voir ce thread en arrivant au bureau ce matin, non que j'attendais avoir eu une réponse mais juste comme ca pour passer le temps. Et là j'ai vu que j'avais vos deux réponses.

Je n'avais pas utilisé ce compte depuis longtemps et l'adresse mail associée n'était plus bonne. Je n'avais pas reçu de notification de vos messages, et j'ignorais que vous vous étiez donné le mal de répondre.

Avec toutes mes excuses, et merci pour vos réponses
Vincent