Discussion :

[yoyodemars]

Bonjour,
Etant débutant et m'initiant a la gestion d'un base de donne Access, j’ai crée une petite application de gestion de contact a but pédagogique.
Je voudrais maintenant utiliser cette base a partir de plusieurs pc. J’ai donc fais des recherches sur la gestion de la concurrence d'accès.
Voila ce que j'en ai compris:
Ado.net gère un accès concurrentiel optimiste, c’est à dire que lors de la mise a jour il contrôle si les datas de base sont les mêmes qu'au moment de la lecture et si ils sont différents il y a une exception qui nous signale qui il y a eu des changements entre temps.
Le problème de cette méthode de fonctionnement est que si deux personnes modifient la même fiche une des deux aura travaillé pour rien.

Y a t'il un moyen de verrouiller la fiche afin que si une deuxième personne l'ouvre elle soit avertit que la fiche est déjà en cours de modification, et puisse l'ouvrir éventuellement en lecture seule pour consultation.

Si il n'existe pas de mécanisme intégré est ce une bonne solution de créer une base "verrouillage" dans laquelle je gère moi même les verrouillages.
En espérant avoir été clair.

Merci d'avance pour vos réponses.

[Nathanael Marchand]

Les bases de données fichier ne sont pas créées pour gérer les accès concurrentiels comme ceci, il serait préférable d'utiliser un serveur de base de données.

[StringBuilder]

Bonjour,

Comme le dit Nathanael Marchand, Access n'est pas prévu pour gérer des accès concurrents.

La solution de gérer des locks logiciels (avec une table comme tu l'as proposé, ou avec un champ dans chaque table) est effectivement une solution de contournement possible.
Seulement, en cas de plantage/déconnexion intempestive d'un client, tu peux te retrouver avec des lignes flaguées comme lockées ad vitam eternam.

La meilleure solution est donc plutôt de t'orienter vers un SGBDR "serveur". SQL Server Express est une très bonne solution : simple à installer/administrer/utiliser, il est pourvu de fonctionnalités bien plus intéressantes qu'Access, et en termes de programmation, tu n'as pas de différence majeure côté code.

PS : A noter toutefois que... c'est bien beau d'avoir une base de données serveur, mais les locks sont toujours à faire "manuellement". C'est à dire que lorsque tu modifies une fiche de contact, il faudra bien penser à lire les données en apposant un lock (select * from matable with ROWLOCK where id = x), sinon tu auras exactement le même problème qu'avec Access.
C'est une chose que peu de développeurs pensent à faire, faisant trop confiance au SGBD, qui ne sait pourtant pas si tu vas modifier ou non les données à l'écran.
=> Pour faire propre, je de gérer comme l'ERP sur lequel je travail : tous les écrans sont disponibles en modif et en visu : quand t'es en visu, il n'y a aucun lock. Ainsi, les utilisateurs qui visualisent des données de verrouillent pas les données inutilement.

[yoyodemars]

bonsoir,
merci de vos réponses.Je vais donc convertir mon application pour sqlexpress et faire des tests.

[p lejarre]

bonjour à tous....

j'ai été programmeur dans l'industrie et les problèmes d'accès concurrentiels je connaissais.

pour faire simple et efficaces, rien de mieux que le bon vieux principe du feu rouge.

je faisais un fichier texte vide... que je testaitbloquait pour la tache T1

bloque table-reservation.conc.txt (qui vérifie le non déjà blocage)
lit nombre de places
diminue nombre de places
écrit nombre de places.
débloque table-reservation.conc.txt

l'autre tache

bloque table-reservation.conc.txt
lit nombre de places
incrémente nombre de places
écrit nombre de places
débloque table-reservation.conc.txt

[sinople]

J'ai un doute mais...

Les LOCKS c'est plutot dans le cadre de transaction que l'on utilise ça non? Et c'est principalement pour éviter l'écriture et non pas la lecture?

Il y a plusieurs façon de gérer ce genre de situation normalement.

On peut dire qu'on s'en fout que quelqu'un d'autre à déjà modifié les données, mes modifications sont de toutes façons mieux alors j'écrase... (Le dernier arrivé gagne). Une façon plus jolie et d'afficher les 2 objets cote à cote est de demander à l'utilisateur ce qu'il veut garder.

On peut dire que c'est pas de bol ce qui t'arrive mais voila... (Le premier arrivé gagne, implémentation par défaut dans ADO.NET). Au passage il suffit d'effacer la partie WHERE de la requête update du tableadapter pour obtenir le 1er comportement. Parfois on vérifie pas l'intégralité des champs de l'enregistrement mais seulement les champs modifiés (2 personnes ont droit de modifier des infos différentes de l'entité en même temps). Parfois on essaye de fusionner les modifications distantes avec les modifications locales et on demande à l'utilisateur de re-vérifier si c'est ok pour lui puis de relancer la procédure (c'est déjà mieux que tout recommancer non?)

On peut dire qu'on bloque l'enregistrement à l'aide d'un drapeau (colonne boolean, Lock?, etc. indiquant si l'enregistrement est vérouillé ou pas) Selon l'implémentation tu peux accepter la lecteur (car tu as désactivé le bouton save...) ou simplement lancer des exceptions de lecture.

Et j'ai propablement oublié un tas d'autre solution. Mais vu le nombre de possibilités, j'espère que tu comprends qu'en réalité c'est à toi de choisir ce qui te convient le mieux et de le mettre en place! (Sachant qu'il n'est pas rare qu'on mixe les méthodes en fonction de la partie de la base de donnée concernée...).

http://www.sqlteam.com/article/intro...-in-sql-server

P.S. Il y a encore un autre sujet passionnant qui est l'implémentation d'un système de notification alertant les autres membres du système qu'il a mis un verrou ou modifié un enregistrement et qu'il faudrait qu'ils mettent à jour ces données précédement chargées afin de rester à la page (ce qui est le comple pour une base de donnée. Ok j'arrête...)

[Graffito]

Comme le dit Nathanael Marchand, Access n'est pas prévu pour gérer des accès concurrents.

C'est inexact: quels que soient ses défauts, Ms Access gère tout à fait les accès concurents et utilise pour cela un fichier .ldb.

Sur le principe de gestion des accès concurrents, il y a 2 approches:

• optimiste : on contrôle à posteriori que l'enregistrement modifié n'a pas été mis à jour par un autre utilsateur depuis le moment de sa lecture
• pessimiste : utilisation du vérouillage.

Voir : http://books.google.fr/books?id=S2NC70luxl8C&pg=PA408&lpg=PA408&dq=acc%C3%A8s+concurent+optimiste+pessimiste&source=bl&ots=5qD9v61Ucg&sig=DlN5OzsxeHVnXktxjom8V97GXb4&hl=fr&sa=X&ei=j79kUOzWCsSq0AXCioDYBw&ved=0CGMQ6AEwCQ#v=onepage&q=acc%C3%A8s%20concurent%20optimiste%20pessimiste&f=false

[iberserk]

Pour faire propre, je de gérer comme l'ERP sur lequel je travail

Propre et ERP dans la même phrase on me l'avait jamais faite

N'y voyez rien de personnel, just a private joke