Discussion :

[bobjoumi]

Bonjour, j'ai une question concernant une petite application que je commence.

Pour des raison spécifique et indépendant de ma volontés la base de donnée de cette application doit être un fichier.

Alors moi direct j'ai pensé a SQL Compact (.SDF)

alors pour le moment c'est juste une gestion de table cela fonctionne très bien quand le fichier est en local mais si le fichier se trouve sur un partage réseau voila le problème que j'ai :

Violation d'un partage de fichier. Le fichier est peut-être utilisé par un autre processus. [V:\Temp\TEST_CAR\Database.sdf]

Le but, est que ce même fichier soit utilisé par l'application qui sera installé sur plusieurs poste distant....

je suis mal partie???

[Er3van]

N'est-ce pas simplement un problème de droit que tu as là ?
Quelles sont les permissions sur le fichier ? Les droits sur le répertoire partagé sont gérés de quelle façon ?

[bobjoumi]

j'ai pensé a ça aussi, j'ai modifié les droits : contrôle total, pour tout le monde

malgré ça, c'est pareil

[Aeronia]

Regarde sur ces liens, c'est apparemment le même problème que toi :

http://stackoverflow.com/questions/9...base-multiuser

http://www.dotnetspider.com/forum/21...or-sql-ce.aspx

[Pol63]

avoir besoin d'une base de données réseau et que quelqu'un te dise que dois utiliser une base de données en fichier est plutot paradoxal

c'est comme si on te disait d'installer directX sur un pc tout en t'obligeant à y mettre linux à la place de windows

il ne faut pas laisser n'importe qui prendre n'importe quelle décision
après je veux bien croire qu'une base de données en fichier partagé ca peut fonctionner, mais ca reste étrange ...

[Bluedeep]

avoir besoin d'une base de données réseau et que quelqu'un te dise que dois utiliser une base de données en fichier est plutot paradoxal

Paradoxal n'est pas exactement le mot que j'aurais choisi.

Jusqu'à plus ample informé, le terme "passablement idiot" me semble plus approprié.

D'autant plus que les gratuits comme Sql Server Express ne laissent même pas place à l'excuse du cout de licence. (l'argument "taille de base" ne semble pas évocable si ils sont prêt à utiliser une base "fichier").

[Pol63]

Paradoxal n'est pas exactement le mot que j'aurais choisi.

Jusqu'à plus ample informé, le terme "passablement idiot" me semble plus approprié.

j'essaye de me modérer en ce moment

[Er3van]

J'ai déjà eu vent d'une problématique de ce type là.

La raison de l'utilisation d'une fichier plat sur un dossier partagé était que l'application ne respectait pas les préconisations de l'entreprise (et pas que...), et donc qu'il n'était pas possible de faire une demande pour un espace serveur, et il fallait que les données puissent être complètement supprimées (au cas où ils se fassent gauler) en moins de 30 secondes.

Dans ce cadre là, le fichier et l'espace partagé se justifie sans doute... enfin, ça prouve bien que c'est à utiliser que dans des cas cradissimes ! xD

[clenoir]

Quand on a des centaines de clients aux 4 coins du monde (et qui parfois ne parlent même pas anglais), qu'on ne veut pas s'occuper de leurs problématiques réseau parce qu'on a déjà suffisamment de difficulté à gérer les différents OS, qu'on a un livrable (contenant le .sdf) que les clients sont susceptibles d'entreposer aussi bien sur un poste local que sur un lecteur réseau ou même une clé USB, c'est quand même bien pratique.
En fait à la lecture du truc j'ai l'impression que le coup du lecteur réseau serait plutôt un cas particulier de l'application qu'une volonté de faire une appli en réseau.

[Pol63]

paramétrer le réseau pour permettre l'accès à un fichier partagé n'est pas plus rapide qu'ouvrir un port si celui ci est fermé ...

[clenoir]

Si le client copie le fichier sur un de ses lecteurs réseaux, il n'a rien à paramètrer puisqu'il y a déjà accès non?
Et l'installation de serveur de BDD est aussi à prendre en compte.

[Bluedeep]

Quand on a des centaines de clients aux 4 coins du monde (et qui parfois ne parlent même pas anglais), qu'on ne veut pas s'occuper de leurs problématiques réseau parce qu'on a déjà suffisamment de difficulté à gérer les différents OS, qu'on a un livrable (contenant le .sdf) que les clients sont susceptibles d'entreposer aussi bien sur un poste local que sur un lecteur réseau ou même une clé USB, c'est quand même bien pratique.

ce n'est pas la conception que j'ai de notre métier mais chacun voit les choses comme il veut.

[clenoir]

Il y a des jours où il faut savoir être pragmatique. Après je n'ai fichtrement aucune idée des contraintes réelles de bobjoumi, et je n'ai fait des suppositions que sur une application qui n'avait pas vocation à être utilisée en réseau à la base.

[bobjoumi]

Je suis content de voir que j'ai ouvert un débat sur ce sujet obscure...
Il n'est pas possible d'ajouter une machine ni d'installé un logiciel sur celles déjà présente.
Mon client dépend d'un grand groupe italien et le service informatique y est centralisé, la communication est très difficile.
Comme je disait c'est une petite application rien d'exceptionnelle. elle doit remplacer un access.
Merci Aeronia je regarderai ça demain au bureau

[clenoir]

En réalité je ne suis pas tout à fait certain qu'il y ait débat. Pol63 et Bluedeep sont parti du postulat qu'il s'agissait d'une application réseau lorsque j'ai pris l'hypothèse d'une application locale avec une BDD volatile. Je pense qu'il s'agit plutôt d'un problème de compréhension que d'un débat de fond.

[Pol63]

@clenoir, je ne pense pas qu'il y a un problème de compréhension

il précise qu'il a un message d'erreur lors du 2ème accès au fichier et qu'il fait une appli multiposte ... ca me parrait clair

de plus une appli avec base de données locale en fichier ne peut pas poser de problème et n'est pas une erreur de conception

[bobjoumi]

je peux vous laisser le code ici si vous voulez...

c'est du 2008

[clenoir]

@Pol63
Quand j'ai lu le post de bobjoumi, j'ai lu qu'il s'agissait d'une application qui serait installée sur plusieurs postes distants, pas qu'il devait y avoir un accès simultané au fichier .sdf. C'est pour cela que j'ai parlé d'un cas particulier de l'application. A mon sens l'utilisateur final pouvait être multi-poste et n'avoir mis le fichier .sdf sur le réseau que pour y accéder depuis différents postes (ou bien rendre disponibles les données qu'avait obtenues son logiciel à un autre utilisateur, effet de bord qui n'est peut-être pas conforme aux spécifications du logiciel).

[bobjoumi]

Effectivement l'application serait installée sur plusieurs postes distants. mais il faut aussi que plusieurs accès simultané soit possible.

Pour faire simple je voudrais remplacer un serveur SQL par un fichier .sdf

Si c'est pas possible tampis je ferais autrement

[clenoir]

En fait je pense que le choix de la solution à adopter dépend de ce que tu vas en faire de ta base de données, et de la manière dont elle risque d'évoluer dans le temps (intuitivement j'associerais une application distribuée à un bon serveur de BDD pour avoir une solution plus robuste et pérenne, mais je crois qu'il vaut mieux une certaine connaissance du logiciel et de son environnement pour statuer). Tu as des limitations au niveau des fichiers .sdf (http://www.microsoft.com/sqlserver/2...ecialized.aspx), et des contraintes/avantages liés à la gestion d'un serveur de BDD. Quid des mises à jours de la base, quels impacts lors d'une migration de parc, ai-je des contraintes de sécurité, comment seront gérées les backups, peut-il y avoir des exigences spécifiques à tes clients, etc. Ce sont des questions qui peuvent se poser avant de se lancer dans une solution.
C'est plus une problématique d'analyse que de développement, aussi vais-je m'arrêter là. Le .sdf peut sembler "cheap", mais un serveur SQL ça peut avoir des répercussions au niveau commercial et maintenance (il vaut peut-être mieux en parler autour de toi si tu veux faire un choix dont tu n'es pas certain).