Discussion :

[elyboss]

Bonjour

J'ai une application Forms développée avec Visual Studio 2008.
Je dois l'installer sur deux machines reliées entre-elles moyennant un réseau local.
Donc deux PC, une seule base de données (Access 2003 mdb).
Le logiciel sera placé dans un seul ordinateur, dans un répertoire partagé pour que l'autre ordinateur puisse y accéder.
Si les deux ordinateurs utiliseront le même logiciel, il va falloir lancer deux instances du même logiciel.
Deux instances, 1 seule base de données.
Quel risque pourrait-il y avoir lorsque les deux utilisateurs effectuent des changements au même moment au niveau de la base de données? (Crash, exception, erreur, etc..).

Au cas-où vous trouveriez cette méthode d'installation peu fiable, que me conseillez-vous?

Merci d'avance à tous.

[Pol63]

access permet la multiutilisateur meme si c'est loin d'etre le meilleur sgbd

après il y a plusieurs options
prenons un exemple d'utilisation

A affiche un tableau, B affiche le meme tableau, A modifie une valeur de 0 à 5 par exemple, B voit toujours 0 et peut mettre 10

si tu codes toi meme tes requetes, il n'y aura pas d'erreur d'execution
dans le 1er cas tu vas faire update set = 5 where pk et dans le 2eme update set = 10 where pk

si tu passes par un dataset, il code lui meme les requetes de mise à jour, et il vérifie au passage que la valeur est toujours la meme
selon le paramétrage du dataset, soit il s'en fout, soit il lève une erreur d'execution
dans ce cas ca te permet d'afficher un message avec l'ancienne valeur connue, la valeur actuelle dans la base et la valeur qu'il voulait mettre, et il choisit laquelle il fait passer

après il y a aussi moyens d'éviter ce genre de situations en rafraichissant les données, soit de manière automatiques toutes les x secondes (on a fait une appli qui rafraichit toutes les 500ms)
du coup, en cas de modif de A, B la voit rapidement (il peut toujours y avoir le cas numéro 1, mais c'est pas forcément grave, c'est à toi de voir selon le type d'application)

sur certains sgbd (comme sql server par exemple), il existe les notifications de requetes
tu fais une requete, tu recois le résultat, et un évènement se lève sur le datareader lorsque des données ont été modifiées et si celles ci modifie le résultat de la requete initiales (donc un peu plus performant, meme si on doit relire tout quand meme)

on peut imaginer une solution intermédiaire moins couteuse en performance mais couteuse en temps de développement, c'est de mettre dans un coin de la base tout ce qui évolue, comme ca chaque client connecté ne lit que ca pour voir s'il y a eut des mises à jour (par exemple stocker la clé de ligne et l'heure)