MS Access concurrency (MDB)

StackOverflow https://stackoverflow.com/questions/694921

Question

Pour un petit projet, je besoin d'utiliser une base de données simple avec des exigences très claires: quelques tables, pas plus que quelques milliers de dossiers au total, 2 ou 3 utilisateurs. Je travaille dans un environnement .NET.

En tant que serveur de base de données (même les éditions Express) semble être un énorme surpuissant dans ce cas, une base de données MDB très simple pourrait faire pour la plupart des exigences. Je suis toutefois préoccupé par la concurrence. Mon idée est de placer le fichier .mdb sur un partage réseau et permettre aux utilisateurs d'accéder à ce fichier de leurs clients .NET. Le db est principalement destiné à opérations en lecture seule, mais les utilisateurs auront besoin de temps en temps de mettre à jour / supprimer des enregistrements ainsi. Si cela ne sera pas possible au moment (en raison de la db étant verrouillé ou autre), je peux tenir les mises à jour sur le client et les traiter plus tard.

La question se passe le long de ces points:

  • Comment sont traitées dans les lectures simultanées MDB?
  • Comment sont mises à jour simultanées / suppressions traitées dans MDB?
  • Y at-il un concept de serrures et comment puis-je tirer parti dans une application .NET?
  • est de placer le fichier MDB sur un bon partage réseau ou horrible idée?

Comme je travaille dans .NET, j'aimerais aussi savoir comment puis-je détecter des problèmes de conflit et de prendre les mesures appropriées. À savoir, quelle exception dois-je prendre et quelles mesures vous recommande de prendre?

EDIT : Peut-être ma mauvaise description du problème, mais la plupart des réponses semblent aller pour un conseiller serveur DB complet soufflé. Je comprends les différences et les avantages d'une installation de serveur et ont en fait mis en place un bon nombre de projets sur MSSQL et Oracle. Dans cette question, cependant, je ne suis concerné par l'accès et ses problèmes de concurrence, donc s'il vous plaît ne suggèrent pas un serveur db.

Merci pour votre aide.

Était-ce utile?

La solution

Ceci est une vieille question, mais personne n'a jamais réellement répondu. Voici les questions:

  1. Comment sont traitées dans les lectures simultanées MDB?
  2. Comment sont mises à jour simultanées / suppressions traitées dans MDB?
  3. Y at-il un concept de serrures et comment puis-je tirer parti dans une application .NET?
  4. est de placer le fichier MDB sur un bon partage réseau ou horrible idée?

Les deux premières questions peuvent essentiellement répondre à une explication. ici une mise en garde clé: les réponses que je donne ici sont spécifiques à Jet (BDM et leurs variantes) et ne sont pas applicables complètement au nouveau format de fichier introduit en commençant par A2007, à savoir, le format ACCDB. Je n'ai pas exploré les conséquences de la suppression de Jet ULS de l'ACE et certains des commentaires ci-dessous peut supposer Jet ULS sous le capot. Pour beaucoup de choses, cependant, vous pouvez remplacer « fichier LACCDB » pour « fichier LDB » et les résultats seront les mêmes.

1-2) / mises à jour Lectures concurrentes / suppressions

Le moteur de base de données Jet est souvent désigné comme une base de données « serveur de fichiers » dans qu'il n'y a pas de démon côté serveur de gestion d'E / S avec les fichiers de données sur le serveur. Ce que cela signifie est que tous les clients utilisant un MDB Jet lisent le fichier directement.

C'est, bien sûr, une recette pour un désastre s'il n'y a pas un mécanisme intégré pour gérer l'accès simultané au fichier.

Jet utilise un fichier-verrouillage d'enregistrement, où si votre MDB est « MyFile.MDB » le fichier de verrouillage d'enregistrement sera dans le même dossier et appelé « MyFile.LDB ». Les enregistrements de fichiers LDB ce que les utilisateurs Jet ULS ont le fichier MDB ouvert, ce poste de travail utilisateur est connecté à partir, et toutes les informations nécessaires à la négociation des questions de concurrence.

Maintenant, pour ceux qui coupent leurs dents sur le moteur des moteurs de base de données client / serveur, cela peut sembler primitive et dangereuse, mais au moment où la base de données Jet a été mis au point, son but était d'être utilisé comme moteur de base de données de bureau pour les petits groupes de travail , et il était en concurrence avec d'autres moteurs db de bureau comme xBase et Paradox, qui utilisent tous deux fichiers de verrouillage analogues pour gérer l'utilisation simultanée des fichiers de données de plusieurs clients.

Dans un fichier de base de données Jet, les verrous sont appliqués soit sur les pages de données (qui Jet 4 ont été augmentés à 4K, alors que dans Jet 3.x et avant, ils étaient 2K), ou au niveau d'enregistrement si la table de données a été créé à l'origine pour utiliser le verrouillage d'enregistrement. Dans les premiers jours de Jet 4, verrouillage niveau record a été trouvé par beaucoup comme assez lent, en particulier lors de l'utilisation verrouillage pessimiste, donc beaucoup de développeurs d'accès jamais rien utilisé mais verrouillage au niveau page (@ David Fenton lève la main!).

En fait, lorsque vous utilisez le verrouillage optimiste, vous évitez la plupart des problèmes de concurrence qui viendrait avec le verrouillage pessimiste.

Quelques mises en garde:

  1. de DAO, le verrouillage d'enregistrement est disponible, et vous ne jamais obtenir le verrouillage de la page.

  2. de DAO, il y a un certain nombre d'options pour contrôler le verrouillage optimiste / pessimiste, en particulier l'argument LockEdits de la méthode OpenRecordset, mais qui interagit également avec certains des paramètres spécifiés dans l'argument des options OpenRecordset (par exemple, Option dbReadOnly ne peut pas être utilisé avec LockEdits). En plus de verrouillage, il existe également des options pour les mises à jour compatibles / incompatibles, et tout cela peut interagir avec les transactions (par exemple, les changements au sein d'une transaction uncomitted ne vont pas être visibles aux autres utilisateurs et ne seront donc pas en conflit avec eux, mais il peut mettre en lecture seule des verrous sur les tables impliquées).

De ADO / OLEDB, ces structures de contrôle d'accès concurrentiel Jet vont être mis en correspondance sur les fonctions et arguments pertinents trouvés dans ADO / OLEDB. Depuis que j'utilise Jet seulement à partir d'Access, je suis en contact avec elle que par DAO, donc je ne peux pas donner des conseils sur la façon dont vous contrôlez ces derniers avec ADO / OLEDB, mais le point est que le moteur de base de données Jet offre le contrôle de votre verrouillage d'enregistrement lors de l'accès il par programme (comme Opposed à via l'interface utilisateur d'accès) -. il est un peu plus compliqué

3) Serrures et .NET

Je ne peux pas offrir des conseils ici, autre que vous utiliseriez probablement OLEDB comme interface de données, mais le point est que la fonctionnalité de verrouillage / contrôle est là dans le moteur db lui-même, donc il y a probablement un moyen de contrôler via OLEDB. Il ne peut pas être assez, mais, comme il me semble que OLEDB est conçu autour des architectures client / serveur, et le verrouillage à base de fichiers de Jet ne peut pas la carte sur cette façon élégante.

4) MDB sur un partage réseau

Jet est très sensible à la moindre hoquet l'une quelconque connexion réseau. À cause de cela, les réseaux à faible bande passante peut augmenter la vulnérabilité des bases de données Jet ouvert sur une connexion lente.

En effet, les principaux morceaux du fichier de base de données doivent être tiré à travers le fil à la RAM de l'ordinateur local pour le traitement. Maintenant, beaucoup de gens prétendent à tort que l'ensemble du fichier MDB est tiré à travers le fil, ou que les tables entières sont tirés à travers le fil. Ce n'est pas vrai. Au lieu de cela, Jet demande d'abord les index (et les demandes pas plus que nécessaire pour remplir la requête), puis de ce résultat détermine exactement les pages de données sont nécessaires et tractions alors que les pages. Ceci est étonnamment efficace et rapide.

En outre, Jet fait une mise en cache très intelligent qui peut signifier qu'une première demande de données peut prendre un certain temps, mais les demandes suivantes pour les mêmes données se produit presque instantanément en raison de la mise en cache.

Maintenant, si vous ne l'avez pas indexé vos tables bien, vous pouvez finir par tirer toute la table et de faire une analyse complète de la table. De même, si vous les critères de base sur les fonctions côté client qui ne font pas partie du dialecte SQL Jet, vous pourriez finir par tirer une table complète (tri, disons, remplacer (MyField, « A », « Z ») est susceptible de causer une analyse complète de la table). Mais ce genre de chose va être inefficace avec une architecture client / serveur, aussi, donc il est juste de bon sens schéma de conception aux choses d'index correctement et faire attention à l'utilisation des fonctions ou des FDU non-Jet compatibles. En général, les mêmes choses qui sont efficaces avec le client / serveur va être efficace avec Jet (la principale différence étant que Jet vous êtes mieux avec une connexion persistante afin d'éviter la surcharge de recréer le fichier LDB, qui est significatif).

L'autre chose à éviter est d'essayer d'utiliser les données Jet sur une connexion Wi-Fi. Nous savons tous combien WiFi est peu fiable, et il vient de demander de mal à essayer de travailler avec des données Jet sur une connexion Wi-Fi.

La ligne du bas:

Si vous utilisez un MDB comme banque de données pour servir les données à partir d'un serveur Web, vous devez mettre les données à proximité de la RAM du serveur Web que possible. Cela signifie que lorsque cela est possible, sur un volume de disque qui est connecté au serveur Web physique. Lorsque ce n'est pas possible, vous voulez une connexion LAN rapide, fiable. Réseaux locaux GB dans les centres de données sont assez communs ces jours-ci et je serais très à l'aise avec les données Jet dans ce genre de connexion.

En commun, par exemple, plusieurs postes de travail clients exécutant une application de bureau VB.NET partager un seul MDB Jet comme magasin de données, il est assez sûr d'avoir le fichier de données sur un serveur de fichiers fiable. Lorsque cela est possible, il est une bonne idée de mettre vos fichiers MDB Jet sur des machines qui ne servent pas à des fins multiples (par exemple, votre contrôleur de domaine qui exécute Exchange, SQL Server et d'agir en tant que serveur de fichiers et serveur d'impression peut ne pas être le meilleur emplacement) . Des applications comme Exchange peuvent mal interférer avec la fonctionnalité de serveur de fichiers, et je vous recommande généralement jamais mettre des fichiers MDB sur un serveur qui est multi-tâches comme un serveur Exchange à moins qu'il est extrêmement faible volume.

Autres considérations:

  1. ne jamais essayer de distribuer un MDB sur un système de fichiers répliqué, à moins que tous les utilisateurs utilisent la même réplique. Autrement dit, si vous avez deux serveurs de réplication des fichiers entre eux, ne pensez même pas à l'édition efichier e MDB des deux serveurs. Ce sera le fichier presque immédiatement corrompu.

  2. Je recommande contre stocker tout MDB sur quoi que ce soit autre qu'un système de fichiers natif de Windows desservis par le réseau Microsoft SMB natif. Cela signifie pas de Novell, pas Linux, pas SAMBA. La principale raison à cela est qu'il ya apparemment des crochets de bas niveau de Jet dans certaines fonctionnalités de verrouillage de bas niveau dans le système de fichiers Windows qui ne sont pas 100% répliquées sur d'autres systsm de fichier. Maintenant, je suis très prudent à ce sujet, et de nombreux développeurs compétents d'accès ont rapporté d'excellents résultats avec les serveurs de fichiers Novell correctement configurés (souvent il doit y avoir quelques ajustements de verrouillage d'enregistrement, bien que peut-être ces jours-ci moins pertinents - Je don sais pas même si Novell existe plus!), et la performance flamboyante avec les serveurs de fichiers basés sur Linux en cours d'exécution SAMBA. Je suis prudent sur ce sujet et recommande à tout client contre (ce qui comprend divers dispositifs SAN, ainsi, étant donné que pas beaucoup d'entre eux sont basés sur Windows).

  3. Je ne les exécuter sur un système de fichiers virtualisés pour les mêmes raisons. Cependant, j'ai un client qui a été en cours d'exécution de son application d'accès à un seul utilisateur sous Parallels sur un Mac Air depuis plusieurs années sans aucun problème. Mais il est mono-utilisateur, de sorte que les problèmes de verrouillage vont être relativement mineures.

Je ne sais pas si cela répond à vos questions ou non. Tout est basé sur mes 13 années d'utilisation régulière de Jet en tant que développeur d'accès et l'étude du seul livre publié sur Jet, la base de données Jet Engine Guide du programmeur (Jet 3.5 uniquement). Je n'ai pas fourni de citations réelles, mais si quelqu'un a besoin de quelques détails sur tout ce que je l'ai dit, je vais faire de la recherche si je peux.

Autres conseils

Je l'ai construit une douzaine de petites applications d'entreprise dans Access au cours des années. La plupart ont un maximum de 10-20 utilisateurs sur eux à un moment. Les bases de données sont réparties entre une base de données « app » et « données ». La performance est bonne et aucun problème avec concurrancy. Aussi la corruption a été essentiellement non depuis Access 2000 existant SP2.

Il y a beaucoup de gens disent « ne jamais utiliser Access » - Eh bien, si elle est bien faite (par exemple par un développeur professionnel) L'accès est tout à fait un programme de développement bien et je l'ai fait une bonne vie à elle. Mes clients sont très heureux avec ce que je construit.

J'ai écrit deux produits commerciaux qui utilisent une base de données Access, en cours d'exécution à partir d'un partage réseau, pour généralement jusqu'à 10 utilisateurs. Si vous ne maltraitez pas, il n'y a vraiment pas de problème; mais comme vous pouvez voir de nombreux développeurs ne reçoivent pas toujours là - et en raison de sa nature bas de gamme, il y a beaucoup de hacks merdique construit là-dessus. Dans le cas d'un produit, je devais revoir l'application à cause de tous les problèmes décrits en détail par d'autres; mais après avoir été nettoyé, je ne ai jamais eu un problème d'intégrité de la base de données à travers des centaines d'installations.

L'un gros avantage est la base de données de fichier unique, qui est facile à sauvegarder, restaurer et copier sur votre ordinateur portable à disséquer. À peu près toutes les alternatives, y compris SQLite (bien que certains ne l'admettra pas), nécessitent une certaine forme d'attention DBA puis maintenant.

Dans la plupart des cas, l'accès fournit des verrous d'enregistrement, et les verrous de fichier pour certains (par exemple les changements DDL de schéma) par défaut.

Mais Microsoft est essentiellement obsolète, et certains de vos collègues méprisantes sur vous pour l'utiliser.

(A ce stade, je normalement canard pour la couverture et crier « ENTRANT !!! ».)

L'accès est vraiment un ordinateur de bureau, solution unique de l'utilisateur. Dans la pratique, il a une limite d'utilisateur supérieure de « un ».

Il est également un moteur local. Autrement dit, lorsque vous exécutez une requête, les données est tirée à travers le réseau au moteur local JET pour le traitement. Un fichier .ldb est placé sur le partage réseau aux serrures de contrôle.

Si vous utilisez un moteur côté serveur (MSSQL, MySQL, Sybase, « Orable etc) alors vous soumettre une requête à un moteur qui traite et renvoie les résultats pour vous. Les verrous sont détenus en interne.

Cela a des implications énormes pour les performances, la stabilité et l'intégrité des données.

Si votre utilisateur décide d'appuyer sur le bouton de réinitialisation, le databse d'accès a une chance d'être corrompu et vous devrez supprimer le .ldb.

Avec un moteur de base de données appropriée (MSSQL, Sybase, « Orable: Je n'aime pas les sauvegardes de MySQL), alors vous aussi une capacité de sauvegarde appropriée. Sauf si vous avez un logiciel whizzy pour sauvegarder inuse fichiers, il est possible que vous aurez pas de sauvegardes de vos données dans le DB d'accès.

je l'ai mentionné serrures spécifiquement parce qu'un moteur db peut gérer et de transaction beaucoup concurrency plus efficacement et avec élégance que tout système basé sur des fichiers.

Je peux voir à l'aide d'un projet Access comme frontal pour un moteur de base de données, mais ne pas investir dans une application client complète avec un back-end d'accès.

J'utilise l'accès, ou plus, Jet comme arrière-plan sur un très petit site privé qui ne peut jamais se développer comme elle est limitée par la taille d'une profession dans ce petit pays. En trois ans, je ne l'ai pas eu de problèmes. Il y a moins de 100 utilisateurs, avec environ trente à quarante en utilisant tous les jours. Les tableaux ont quelques milliers de dossiers.

Je n'ai pas beaucoup d'expérience avec Access, mais ce lien peut être utile pour vous:

http://office.microsoft.com/en-us/access /HP052408601033.aspx

"Vous pouvez mettre la base de données complète d'accès sur un serveur réseau ou dans un dossier partagé. C'est la méthode la plus simple à mettre en œuvre. Tout le monde partage les données et utilise les mêmes formulaires, des rapports, des requêtes, des macros et des modules. Utilisez cette stratégie si vous voulez tout le monde à utiliser la base de données d'accès de la même manière ou si vous ne pouvez pas aider les utilisateurs à créer leurs propres objets. "

"Lorsque vous ouvrez un fichier de base de données Access (.mdb) en mode partagé, Microsoft Access crée également un fichier d'informations de verrouillage (.ldb) avec le même nom de fichier (par exemple, Comptoir.ldb) et dans le même dossier que le fichier de base de données. ce fichier d'informations de verrouillage stocke le nom de l'ordinateur (comme mypc) et le nom de la sécurité (comme admin) de chaque utilisateur partagée de la base de données. Microsoft Access utilise ces informations pour contrôler la concurrence. Dans la plupart des cas, Microsoft Access supprime automatiquement le fichier d'informations de verrouillage lorsque le dernier utilisateur ferme le fichier de base de données. "

L'accès est censé être multi-utilisateurs - Je pense que Microsoft recommande jusqu'à 4 ou 5 utilisateurs, mais en pratique, je vous recommande d'utiliser jamais une base de données d'accès où il y a plus d'un seul utilisateur, bien que si vous n'avez pas vraiment le choix, il est acceptable pour deux ou trois, étant donné certaines nuances.

J'ai eu l'expérience de quatre ou cinq systèmes utilisant une base de données Access back-end - tous acquis auprès d'autres « développeurs » - et dans tous les cas, je les ai déplacés à SQL Server comme une priorité après les mises à jour immédiates et fixe requis lors de la prise du contrat - en général, dès que je pouvais parler le patron de payer la facture en elle. durée de temps pour cela est généralement plusieurs mois, donc je l'ai vu courir en même temps pour une durée raisonnable dans plusieurs applications différentes.

En fait, il fonctionne généralement bien si le Praticable système n'a pas beaucoup d'insertions / mise à jour simultanée et n'est pas très utilisé. Les principaux problèmes pratiques dans mon expérience sont ..

  1. Il est responsable de la corruption - il fait juste. En général, ce n'est pas trop d'un problème que l'ouverture du fichier en cours d'exécution et compact et réparation triera les problèmes, mais un bon régime de sauvegarde est absolument indispensable.

  2. Il est lent. Chaque fois que je l'ai mis à jour un système à SQL Server j'ai reçu beaucoup de félicitations pour accélérer le système des utilisateurs.

  3. Le fichier de base de données gonflerait en raison de la façon dont l'accès marque les enregistrements comme mis à jour ou supprimé. Cela ralentit davantage le système que le fichier doit être chargé à travers le réseau. Par conséquent, un certain régime qui compresse les données, généralement sur une base quotidienne, est essentielle.

Toutes ces sont beaucoup moins d'un problème avec un seul utilisateur que les problèmes sous-jacents qui demandent à ces derniers sont beaucoup moins importants.

Dans l'ensemble, je dois souligner que je ne recommanderais jamais accès à tout système multi-utilisateurs. Toutefois, si vraiment avoir trop vous aurez probablement avec elle aussi longtemps qu'elle est une application légère utilisée et vous faire engager les procédures de sauvegarde et de maintenance.

Il a déjà été dit à plusieurs reprises d'utiliser un vrai multi-utilisateurs, la plate-forme de base de données libre. Mais l'une des raisons pour lesquelles n'a pas été déclaré. Cette raison est, combien de bases de données existantes, en désordre, gênants, un grand accès ont commencé comme « quelques dossiers, un ou deux utilisateurs max »? Je me risquerais à dire tous.

A moins qu'il n'y a que deux ou trois employés dans toute l'entreprise, les chances sont que si vous développez un morceau utile de logiciel, il va éventuellement être utilisé par plus de deux ou trois originaux utilisateurs, ont plus que l'original quelques milliers de dossiers, et se développer au fil des années pour inclure de nombreuses formes, beaucoup plus de tables, et beaucoup plus de données. Vous ne pouvez pas refaire la fondation d'une maison une fois que la maison est construite. Construire une base solide aujourd'hui, et vous pouvez étendre la maison au contenu de votre cœur. Idem pour le logiciel.

Lorsque vous allez avec un partage réseau j'aller avec un réseau base de données activée (mysql / firebird / MSSQL) au lieu d'accès.

Pour la situation de votre description en utilisant l'accès ne serait pas un problème.

Je l'ai utilisé dans des situations d'accès plus difficiles alors ce surtout lorsque l'on travaille avec des sites Web lorsque l'accès est pas abusé au-delà de la mesure, il est vraiment pas si mal d'un moteur de base de données. (Ne parle pas de formes et des trucs comme ça seulement des tables et des enregistrements)

Lorsque vos inserts font / mises à jour / suppressions de plusieurs utilisateurs à la fois, alors il devient un peu poilu. C'est le point où vous commencez à penser sur les moteurs de base de données réelles.

De même, lorsque vous voulez une faible base de données qui est en tête du fil de sécurité, vous pouvez jeter un oeil à VistaDB (plus lent que l'accès, pas toujours libre, 100% .NET)

Je pense que l'accès utilise le niveau verrous de table avec une sorte de queeing choses mécanisme devrait bien fonctionner. Si votre inquiet à ce sujet, vous pouvez toujours jeter un test d'effort simulé dans ce domaine.

Je pense que vous pouvez définir dans votre chaîne de connexion d'applications .net. Je googlé pour JET, l'accès et le verrouillage des enregistrements

qui pourrait aider.

S'il vous plaît voir la réponse acceptée pour plus de détails réels sur la façon dont l'accès et JET obtenir des données.

S'il vous plaît ne pas utiliser l'accès pour un scénario multi-utilisateur.

Je viens juste de passer par deux semaines de douleur parce que mon predeccessor sur un projet choisi Access comme arrière.

raisons de béton:

  • Il n'y a pas une telle chose comme Linq-to-Access
  • L'accès a de nombreuses bizarreries comme les dépendances de l'ordre d'addition des paramètres aux commandes qui vous amène à l'âge debug
  • L'accès n'échelle pas
  • Mises à jour de base de données sont une corvée par rapport à l'utilisation de SQL Server
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top