Application WPF et accès concurrents SQL Server

Bonjour,

Je suis à la recherche de cours/tutos et autres informations concernant les accès concurrents sur une base de données SQL Server dans le cadre d'une application client lourd WPF.

Je travaille sur une application qui accède à une base de données sur serveur. Celle-ci est disponible sur plusieurs postes de travail et donc il y a plusieurs accès à la base SQL de manière simultané.

Je cherche donc des tutos qui explique bien comment éviter les divers problèmes se présentant à moi.

Par exemple on accède à une ficher qui est modifié pendant qu'on la regarde, les infos affichées ne sont plus valides.
Si l'on enregistre, les modifs du collègue sont effacées. etc...


Merci pour vos réponses (par avance)

Ce n'est pas vraiment une question technique mais plus une question de besoin... Avant de te lancer dans le code, défini le comportement que tu souhaites avoir dans les différents cas.

Sinon d'un point de vue technique : transaction, concurrence optimiste ou pessimiste...

Je pense que ce que tu recherches sont les transactions.

Je ne sais pas comment tu fais tes connections actuellement, mais voici un lien qui pourrait te servir :

http://msdn.microsoft.com/fr-fr/libr...vs.110%29.aspx

Citation:

---

Avant de te lancer dans le code, défini le comportement que tu souhaites avoir dans les différents cas.

---

Je suis arrivé sur un application en partie déjà réalisé. Mais je réalise des fonctionnalités en plus tel que ajouter/modifier une commande (achat) par exemple.

Citation:

---

Je ne sais pas comment tu fais tes connections actuellement,

---

Il s'agit d'une BDD créer via un diagramme fait avec Visual Studio (.edmx).
C'est donc un composant ADO.NET

La chaine de connexion est spécifié dans app.conf

Après je fais mes modifs sur mon context et je fais moncontext.save().


Admettons que mon appli m'affiche une liste de nom.

Je démarre 2 appli; lorsque dans la 1ere ajoute un nom à cette liste celui-ci n'apparait pas dans l'autre application.

Comment gérer ça ? Car le context de la première n'ai pas mis à jour et la dessus je suis un débutant.


En fait mon appli appel directement le SGBD, il n'y a pas d'application serveur.
Il faudrait donc que je remette à jour les infos en rame (le datacontext).

Pour rafraichir ton application en cas de modification de la base de données, tu peux utiliser la classe SqlDependency. Lorsqu'un changement surviendra dans la base SQL Server, dans le jeu de données que tu souhaites surveiller, l'évènement OnChange sera alors déclanché et tu pourras agir en conséquence.

Pour l'utiliser avec Entity Framework, tu peux regarder ce projet et t'inspirer de ce qu'ils ont fait: How to use SqlDependency to get the notification in Entity Framework.

Ok, jvais commencer par regarder dans cette direction.

J'ai quand même trouver divers choses dont je ne suis pas sûre..

Le premier :

Code:

---

1 2	_Context.CommandeFournisseurs.MergeOption = MergeOption.PreserveChanges;

---

J'ai trouvé ceci qui m'a l'air de mettre à jour mes infos lorsque je demande au contexte de me redonner le détail d'une commande si je mets à jour via une requête sql avant il a l'air de me donner le résultat mis à jour.

Mon deuxième point :

Code:

---

DataAccess.EntitiesContext.Context.Refresh(System.Data.Objects.RefreshMode.StoreWins, DataAccess.EntitiesContext.Context.CommandeFournisseurs);

---

Je pense que sa reload mes informations à partir de ma source. Petit problème j'ai un peu peur pour les perf car 5000 lignes mettent un peu de temps à s'afficher... (peut-être problème de GUI wpf)



Quels sont vos avis sur ces points ?

Il n'existe pas de solution magique. L'information entre une couche de données (comme un DB) et la couche de présentation (WPF, HTML, etc.) sera désynchronisée du moment où un 'snapshot' est fait de l'"état" des données.

Pour pallier à ce fait, il existe des méthodes qui permettent de réduire la désynchronisation.

Par exemple, il est pertinent de cacher (dans le sens de mettre dans une cache...) des données qui sont souvent consultées mais rarement modifiées. Et lorsqu'elles sont modifiées, l'opération peut être encapsulée dans une transaction qui garantit que les utilisateurs ne reçoivent pas de données "sales" et qui rafraichit du coup les caches en mémoire.

Une autre piste sont les '5000 lignes à afficher'. Vraiment, l'utilisateur a besoin de voir 5000 lignes? Ne pourrait-il pas travailler avec des pages de 50 lignes? En faisant de la pagination, ça réduirait la lourdeur de 99%...

Citation:

---

Envoyé par Babyneedle

Une autre piste sont les '5000 lignes à afficher'. Vraiment, l'utilisateur a besoin de voir 5000 lignes? Ne pourrait-il pas travailler avec des pages de 50 lignes? En faisant de la pagination, ça réduirait la lourdeur de 99%...

---

Pour les 5000 lignes effectivement c'est un de mes futurs changements pour load les informations (enfin la liste) au fur et à mesure que l'on scroll. A savoir que j'ai des filtres sur cette liste donc...

Après je crée un objet contexte avec le code que me génère le diagramme.

Code:

---

Pour pallier à ce fait, il existe des méthodes qui permettent de réduire la désynchronisation.

---

Oui, j'ai trouvé le refresh et le mergeOption mais je ne sais pas laquelle est la plus adéquate...

Le refresh recharge l'objet à partir de la source apparemment alors que le mergeOption reste très obscur en ce qui me concerne (je cherche toujours à ce sujet).

J'aimerais coder proprement sans faire de bêtises et d'aberration.

il y a plusieurs possibilités

l'une d'entre elle est utilisée dans le dataadapter si j'ai bien suivi, c'est qu'au moment de l'update il y a vérification si la valeur est toujours la même qu'au moment auquel cas de l'écriture se fait sans poser de question, dans le cas contraire (modification par un autre poste entre la lecture de ce poste et l'écriture) c'est au développeur de choisir (en amont ou en aval via l'utilisateur) de décider s'il faut ou non écrire par dessus

une autre possibilité évoquée précédemment c'est les notifications de requete d'sql server, celui ci peut etre configuré pour "lever un évènement" en cas de modication de données retournées par une requete, permettant de mettre à jour l'interface, outre le fait que ca ne fonctionne pas sur les versions express et que ca peut couter un peu de performances (c'est peu optimisé) ca reste à mon avis moyennement utilisable, genre en cas de modification juste avant la demande d'écriture, mettre à jour le tableau affichant les données n'aidera pas

il reste une possibilité qu'on utilise nous, c'est de rafraichir les données souvent sur les tableaux avec des données sensibles et/ou modifiées souvent
même sur quelques milliers de lignes toutes les 500ms ca ne nous pose pas trop de problèmes, mais ca ne convient pas forcément dans tous les cas

dans tous les cas c'est à toi de décider en fonction des besoins de ton programme ...


concernant la pagination, je trouve ca très orienté web où les temps de transfert sont plus long qu'en local, nous sur un lan ca ne nous dérange pas d'afficher des tableaux avec des centaines de milliers de lignes, ca reste assez rapide si c'est bien codé

Citation:

---

l'une d'entre elle est utilisée dans le dataadapter si j'ai bien suivi, c'est qu'au moment de l'update il y a vérification si la valeur est toujours la même qu'au moment auquel cas de l'écriture se fait sans poser de question, dans le cas contraire (modification par un autre poste entre la lecture de ce poste et l'écriture) c'est au développeur de choisir (en amont ou en aval via l'utilisateur) de décider s'il faut ou non écrire par dessus

---

Pour ça je comptais enregistrer la date de mise à jour lors de l'enregistrement ce qui me permettra de vérifier que la date n'est pas la même qu'au moment de la lecture.

Mais le deuxième problème est lors de l'ajout d'une ligne il faut que j'actualise le tableau des autres applications.

Ma BDD et représenter via un objet context qui est chargé en mémoire.

Utilisant MVVM avec WPF et Entity Framework je voudrais respecter ce système. Mais étant débutant ce n'est pas évident.
Tous est géré avec des objets et il n'y a pas de SQL.

D'où mes questions concernant le refresh et le mergeOption. Je ne connais pas le composant Ado.net et sont comportements...

le problème c'est surtout de débuter
soit tu apprends tout et tu codes tout toi même et tu peux faire ce que tu veux facilement
soit tu utilises la simplicité (comme EF) et autres assistants et tu n'as plus la main sur le code, donc il devient difficile de sortir des sentiers battus
enfin avec EF tu peux sortir des sentiers battus et remplacer tous les comportements par défaut, mais ce n'est pas plus simple à apprendre que les choses de bases (les classes et membres sont partial etc...)