Discussion :

[Lionhart]

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)

[meziantou]

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...

[Dynamès]

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

[Lionhart]

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.

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).

[DotNetMatt]

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.

[Lionhart]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[Babyneedle]

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%...