Discussion :

[JoeChip]

Normalement, on fait ça avec une base de données, il n'y a aucune raison logique de ne pas le faire. A la base, faire ça avec un fichier excel est une erreur (voire une faute...).

Je ferais une BDD avec entre autres une liste de users, et ce qu'ils peuvent faire comme modifs, avec un admin qui peut faire ce qu'il veut. Rien que des choses très banales, ça n'a vraiment rien de très particulier comme appli, c'est même hyper-classique depuis au moins les années 1960. Ton tuteur de stage n'est pas développeur, visiblement... Rien que l'idée de faire ça sous excel est absurde, alors que Access, déjà, fait ça mieux. D'ailleurs, en fait, le mieux c'est d'utilsier Access, à mon avis.

[hwoarang]

Encore une fois, le probleme ne vient pas de xml ou de droits qu'auront ou pas les utilisateurs. A partir du moment ou il peut y avoir 2 personnes qui modifient un meme fichier, il y a un risque en cas de modification simultanée. Il faut donc voir avec ton tuteur si le risque de corruption de données est acceptable. Et si non, utiliser une BDD. Il n'y a pas 36000 solutions. On peut tourner autour du pot encore longtemps, en parlant de droits, de sécurité ou de serveur mais on en reviendra toujours au meme point.

[Carvallegro]

Trés bien merci,
Je vais essayer de négocier ça avec lui, je reviendrai vous dire ce qu'il m'a dit

[tchize_]

Au passage, faire une petite application "serveur" qui tournerais sur la machine du tuteur en démarrage automatique. C'est moche, c'est anti production, mais au moins, le problème de concurrence est réglé.

De plus, si chacun peux changer des données différents, il serait plutot préférable de partir de l'idée que chaque "employé" a son propre fichier avec uniquement ses données et que l'application merge ces fichiers à l'écran, non?

[Népomucène]

D'ailleurs, en fait, le mieux c'est d'utilsier Access, à mon avis.

Je plussoie

... si les postes sont sous Windows.

Cela me fait bizarre dans un forum java de recommander Access mais, si tu connais un peu Access, tu vas pouvoir régler le problème en deux coups de cuillère à pot.

[tchize_]

Attention que, si le réseau est controlé par l'administration centrale, une base de données access, autant que je sache, a la réputation de pas mal "crier" sur le réseau

[Népomucène]

Bonjour Tchize

Qu'entends-tu par crier ?

[tchize_]

beaucoup de broadcast

[Népomucène]

Ah ben ça c'est possible.

La gestion de verrou par Access se fait avec un petit fichier ldb placé à côté de la base mdb.
Dans ce système, il n'y a pas de serveur de base et les accès concurrents sont gérés par chaque Access installés sur les postes !

En pratique ça marche bien tant qu'on ne dépasse pas une dizaine d'utilisateurs.
Donc pour @Carvallegro cela devrait convenir s'il ne trouve pas son bonheur avec Java.

En java, il est clair que la solution la moins mauvaise est celle que tu as suggéré :
- le fichier XML installé sur un poste
- une application serveur en java qui attend les requêtes des utilisateurs sur un port convenu
et qui se charge des ajouts/modifications/suppressions/consultation
- l'application cliente (sur les postes) qui communique avec le serveur par socket

[tchize_]

Ah ben ça c'est possible.

La gestion de verrou par Access se fait avec un petit fichier ldb placé à côté de la base mdb.

T'es sûr qu'il n'y a que ça? Parce que, dans l'absolu, ce n'est pas fiable. tu pourrais avoir 2 poste qui crée ce fichier en même temps. Le protocole CIFS dans certaines condition va laisser passer.... C'est justement ce qui empêche SQLLite de travailler en montage réseau :/

[Népomucène]

Ben oui.
Ce fichier est créé lors du premier accès à la base mdb par Access.
Ensuite chaque utilisateur qui se connecte sera enregistré dans le ldb avec des infos de sécurités
et des locks sur des pages de données (je n'ai pas les détails mais en gros c'est ça. Plus d'info : http://support.microsoft.com/kb/208778/fr)

Après, quand tout le monde est parti, le fichier ldb est supprimé.

Le système n'est théoriquement pas idéal mais franchement, après l'avoir utilisé pendant des années
les plantages sont rares à condition de bien concevoir la base.
J'ai même fait une gestion de production pour une usine qui tournait 24h/24h avec une base Access.
Il n'y avait que 20 postes de connectés (cela dit, après 3 ans d'utilisation, on est quand même passé à Oracle).

Il est clair que la solution Access est limitée à quelques utilisateurs.