2015-10-29 8 views
2

Je développe une application qui utilise comme back-end une base de données MS Access (.mdb, pas ma décision). Récemment, je suis tombé sur quelqu'un qui suggère que l'utilisation du moteur JET sur WAN n'est pas vraiment une bonne idée, avec un risque élevé de corruption de données. Étant donné que mon application doit faire cela (connexion à la base de données sur NAS (EDIT: pas NAS, Shared Network Shared Drive), je me suis inquiété.Il est vraiment risqué? Si oui, y at-il un travail ou une base de données MS Access juste inutilisable pour ce genre d'application?Risque de corruption des données sur le réseau WAN avec la base de données Access partagée

EDIT

l'extrémité avant est windows .NET application de bureau en C# (WPF). le système n'a pas beaucoup d'utilisateurs, max 10. la plupart du temps, ils s'approche de la base de données à partir du LAN et 99% de l'écriture dans la base de données se fera dans le LAN (à partir de la zone de l'entreprise), mais dans certains cas, ils se connecteront au NAS. conduire) de l'extérieur de l'entreprise via le réseau (de leur domicile).

+0

Vous devez ajouter beaucoup plus d'informations comme: Qu'est-ce que le frontal? J'ai un mdb sur un site Web pendant de nombreuses années. Il y a très peu d'utilisateurs et très peu d'édition. Tout fonctionne avec ASP classique. – Fionnuala

+0

Désolé, voir mon édition, merci. – MartinVotruba

+0

Pouvez-vous utiliser Remote Desktop pour les utilisateurs qui se connectent depuis l'extérieur du LAN? – HansUp

Répondre

0

La division d'une unité frontale à partir d'une unité principale supprime la majorité des risques de corruption. Bien sûr, avec Access, il y a toujours la possibilité et si vous cherchez quelque chose qui réduit le risque à près de zéro alors vous pourriez envisager SQL Server ou MySQL. Cependant, l'utilisation d'Access est correcte tant que vous prenez les précautions appropriées. Par exemple, vous voudrez peut-être vous intéresser au verrouillage des enregistrements sur les tables qui seront éditées, afin d'éviter plusieurs écritures simultanées. Sauvegarder votre base de données régulièrement est toujours bon.

1

Si vous avez une fibre de 100 Mb/s, ce sera OK, mais si votre ligne est, disons, une ligne xDSL, c'est généralement un non-non absolu. Convaincre le pouvoir de déplacer le backend vers un moteur de serveur tel que SQL Server où la version Express est libre.

1

Le scénario que vous décrivez ne convient pas pour avoir une base de données Access en tant que back-end. Les utilisateurs du WAN pourraient très bien trouver l'application lente, mais le NAS est la vraie source de préoccupation concernant la corruption, et cela affecterait les utilisateurs LAN et WAN.

De nombreux périphériques NAS (la plupart?) Fonctionnent sous Linux et utilisent Samba pour fournir des services de partage de fichiers Windows. Le moteur de base de données Access utilise apparemment certaines fonctionnalités de bas niveau du "vrai" partage de fichiers Windows que Samba n'implémente pas toujours complètement (réf: here). En fait, la seule fois où j'ai vu des problèmes de corruption répétés avec un back-end Access partagé (et une interface frontale correctement distribuée) était lorsqu'un client déplaçait ses partages de fichiers d'un ancien serveur Windows vers un NAS plus récent. dispositif. L'application Access continuait à fonctionner pour la plupart, mais tous les quelques mois, ils trouvaient que les clés primaires de certaines tables disparaissaient après avoir effectué un compactage et une réparation sur le fichier de base de données principal. Cela n'est jamais arrivé pendant que leur partage de fichiers était sur le serveur Windows.

+0

Désolé, je n'ai pas précisé le problème correctement, ce n'est pas un NAS mais juste un lecteur réseau régulier, je n'ai pas réalisé qu'il y a une différence. Donc vous dites que ça devrait aller? – MartinVotruba