Est-MS Access (JET) adapté pour l'accès multi-utilisateur?

Question

J'ai un produit conçu pour être un produit de bureau en utilisant le fichier MS Access comme base de données.

Maintenant, certains utilisateurs doivent installer dans quelques PC (disons 2 ou 3) et partage la base de données.

Je pensais que placer le fichier MS Access dans un dossier partagé et accéder à partir du PC, mais ... le moteur JET est conçu pour un accès multiutilisateur?

Des conseils ou des choses à être au courant de le faire?

EDIT: L'application est un .net une, en utilisant la base de données de stockage (non en utilisant la base de données comme frontend)

Answer 1

Il y a tellement de désinformation dans les réponses sur ce sujet que je ne sais pas où commencer. Je viens de passer 4 points dans la réputation de voter les réponses avec des informations trompeuses et le mal en eux.

1. le moteur de base de données Jet (qui est tout ce qui est en cause ici, comme l'OP clarifié avec une modification) est par défaut multi-utilisateur -. Il a été construit à partir du sol pour être de cette façon

2. partager un magasin de données Jet est très fiable lorsque le réseau ne sont pas inférieurs aux normes. Cela ne signifie pas un WAN et non sans fil, car la bande passante doit être suffisante pour Jet pour maintenir le fichier LDB (pour le verrouillage multi-utilisateurs), ce qui signifie un ping par l'instance de votre PC local du moteur de base de données Jet une fois par seconde (avec les paramètres par défaut), et parce que Jet ne peut pas se remettre d'une connexion a été interrompue (ce qui est assez fréquent dans un environnement sans fil).

3. la situation où l'accès tombe est lorsqu'une application d'accès frontal MDB est partagé (ce qui est le cas pour cette affiche). La raison pour laquelle il échoue est parce que vous partagez des choses qui ne peuvent pas être fiable et partagées ont aucune raison d'être partagée. En raison de la façon dont les objets d'accès sont stockés dans un fichier MDB (l'ensemble du projet d'accès est stocké dans un seul champ BLOB dans un enregistrement dans l'une des tables du système), il est très sujette à la corruption si plusieurs utilisateurs ouvrent. À mon avis, le partage d'une extrémité avant d'accès (ou un MDB unsplit avec les tables et les formulaires / rapports / etc. Tout en un MDB) est la source de 99,99% des corruptions de fichiers Access / Jet.

Ma réponse fondamentale à la question de l'OP est que, oui, Jet serait un grand magasin de données pour une application de cette taille. Cependant, s'il y a la moindre possibilité pour la population d'utilisateurs de croître au-dessus de 25, alors il pourrait être préférable de commencer à partir de zéro avec un moteur de base de données qui est plus robuste aux populations d'utilisateurs plus.

Answer 2

Il est parfaitement possible de le faire; mais vous devez diviser la base de données en une extrémité avant (avec des formes, des requêtes, le code) et une extrémité arrière (uniquement les données). Chaque utilisateur doit avoir l'avant sur leur propre ordinateur, un lien vers la fin commune de retour.

Il sera lent que Jet génère une tonne de trafic réseau. Microsoft est également désapprouver progressivement Access comme outil de développement. Access 2007, par exemple, a un modèle de sécurité beaucoup moins sophistiqué que Access 2003.

En tant que développeur de temps d'accès Je déménage progressivement de l'accès.

Answer 3

Ne pas le faire ... la base de données Jet prétend être capable de supporter plusieurs utilisateurs, mais il est incroyablement facile à utiliser l'assistant de migration pour convertir votre fichier d'accès à une base de données Sql Express. Ce fichier de base de données pourrait facilement devenir verrouillé par un utilisateur ou administrateur, et tous vos utilisateurs ne pourront pas utiliser la base de données.

... et Express est gratuit Sql . Votre chemin de mise à niveau à partir de là à une instance complète de SQL Server ou une autre base de données commerciale est simple.

Answer 4

Avec 2 ou 3 utilisateurs sur un réseau local fiable, vous devriez être bien, aussi longtemps que vous sauvegardez le lecteur réseau souvent.

Évitez tout bit / champs booléens dans vos tables -. Jet a des problèmes de corruption désagréables avec accès multiple à les

Gardez aussi à l'esprit que tout blocage dans Access est optimiste:. Vous obtiendrez lit sale de temps en temps

MS Access est conçu pour les petits scénarios de bureau comme celui-ci:. L'utilisation de bureau de lumière non critique que vous pouvez configurer avec le minimum de programmation

Attendez-vous le fichier de données est corrompue chaque maintenant et puis -. Retour régulièrement

Answer 5

Le ACE / moteur Jet est un grand morceau de logiciel, mais, alors qu'il était conçu pour soutenir plusieurs utilisateurs, plusieurs utilisateurs soutiennent en fait dans la pratique n'est pas un de ses points forts. La goutte d'eau pour moi est là alors la sécurité au niveau utilisateur supprimé (ULS) du moteur: je suppose que je peux imaginer une situation de simple base de données où tous les utilisateurs auront les mêmes privilèges (accès admin toutes les bases de données objets), mais l'OMI qui ne supporte pas bien plusieurs utilisateurs, par rapport, par exemple, MS SQL Server.

Answer 6

Oui, il prend en charge l'accès par multiple (qui est, une petite taille de groupe de travail, le nombre) d'utilisateurs sur un partage de fichiers réseau. Cependant, l'architecture de partage de fichiers est tout simplement pas idéal pour soutenir l'écriture simultanée à un fichier par plusieurs utilisateurs. Un système de base de données client / serveur (SQL Server, etc.) fournit généralement de meilleures performances, la sécurité et la fiabilité.

Answer 7

En tant que sysadmin, s'il vous plaît ne pas utiliser quoi que ce soit pour l'accès multi-utilisateurs. Faites ce que Jeff Fritz suggère et utiliser une base de données qui est conçu pour un accès multi-utilisateurs. Vous pouvez penser que votre petite application ne va être partagé entre quelques personnes, mais je vous garantis que cela va avoir une centaine d'utilisateurs et une cinquantaine de nouvelles fonctionnalités d'ici la fin de l'année. Et si ce sont tous les accès, plutôt que VB / SQL Express, votre Ops se répartiront dans votre maison une nuit et fente la gorge.

L'accès n'est pas une application client-serveur, et fournit très peu de la manière de sauvegarde / restauration, ou de toute automatisation que ce soit. Sans parler de l'interface et la DB sont très étroitement couplés ... donc si vous voulez jamais transformer cela en une application web, ou de faire des changements sérieux, votre monde sera rempli de douleur.

Answer 8

Il a été fait tant de fois par tant d'ingénieurs logiciels génériques où nous avons vu un .mdb aller corrompu dans une situation multi-utilisateur. Si tant de spécialistes expérimentés développeurs d'accès peuvent obtenir le droit, comme je suis porté à croire, nous les généralistes doivent faire quelque chose de mal et que quelque chose doit être assez fondamental mais non évidente pour beaucoup d'entre nous de fuir la chose criant «plus jamais! Donc, si vous vous considérez comme un développeur d'accès spécialiste expérimenté (ou vous savez comment trouver un) puis aller. Mais si vous êtes un utilisateur occasionnel ou généraliste recherche d'un arrière léger alors je vous suggère de regarder ailleurs (SQL Server est bon OMI).

Answer 9

Si vos utilisateurs peuvent attendre deux fois plus longtemps pour une application avec la moitié des fonctionnalités qu'ils veulent, alors ne pas utiliser Access.

Answer 10

Jet n'a pas la logique de verrouillage sophistiqué nécessaire pour supporter des scénarios multi-utilisateurs. Vous pouvez vous contenter de l'utiliser si votre application est la plupart du temps et lit à faible affirmation.

Je l'ai vu de nombreux utilisateurs des sites Web prennent en charge, mais je vous recommande SQL Express sauf si vous avez une raison impérieuse de choisir Jet.

Answer 11

Je peux vous dire de l'expérience douloureuse que Jet 3 / 3.5 n'était pas fiable. Je l'ai vu planter souvent sous une charge légère et quand il y avait des accidents vous risquais la corruption de données. Il fut un temps extrêmement sensible aux problèmes d'alimentation, tout client s'écraser contre elle (même l'interface utilisateur liée au mdb), et des problèmes LAN. Des versions plus récentes de Jet pourraient être mieux, mais le passage à Sql Server est clairement la voie à suivre à mon avis pour autre chose que la saisie des données trivial avec un petit nombre d'utilisateurs. Sql Express est gratuit et vous ne perdez pas vraiment quoi que ce soit, surtout si vous êtes l'interface utilisateur est en .Net, plutôt que l'accès.

EDIT:. Microsoft ne pense pas que vous devriez compter sur Jet 4 soit

à partir de: http://support.microsoft.com/kb/303528

Microsoft Jet n'est pas destiné à être utilisé avec des applications de serveur de stress élevé, les applications de serveur haute, ou 24 accès concurrentiel heures par jour, sept jours applications serveur semaine. Cela inclut les applications serveur, telles que les applications Web, les applications de commerce électronique, les applications transactionnelles et les applications de serveur de messagerie. Pour ces types d'applications, la meilleure solution est de passer à un véritable client / système de base de données sur serveur, tel que Microsoft Data Engine (MSDE) ou Microsoft SQL Server. Lorsque vous utilisez Microsoft Jet dans les applications à haut stress tels que Microsoft Internet Information Server (IIS), vous pouvez rencontrer l'un des problèmes suivants: corruption de base de données Problèmes de stabilité, tels que IIS blocage ou le verrouillage Une panne soudaine ou l'échec persistant du conducteur de se connecter à une base de données valide nécessitant le redémarrage du service IIS

Answer 12

juste vérifier si le fichier de verrouillage db (comme .ldb) est là ou non. Si elle est là, quelqu'un accède à ce fichier. Si elle n'y est pas, à l'heure actuelle il n'y a pas un accès à ce fichier et vous pouvez continuer. Sinon, attendez lorsque ce fichier (.ldb) est plus existant.

Answer 13

Si vous utilisez un Terminal Server, la performance est bien réel. Nous avons plus de solutions jusqu'à 50 utilisateurs à un mdb d'accès. Le développement est rapide et réel déploiement facile.

Problèmes:

• tout le monde peut copier mdb de données
• aucun droit d'accès
• procédures de magasin limité
• optimize (compression et réparation) possible sans base de données de données d'utilisation
• limite à 2 Go!