Des problèmes lors de l'utilisation de MS Access comme frontal pour un back-end de base de données MySQL ?

Question

Deux utilisateurs souhaitaient partager la même base de données, initialement écrite dans MS Access, sans entrer en conflit sur un seul fichier MDB.

J'ai déplacé les tables d'une simple base de données MS Access vers MySQL en utilisant son Boîte à outils de migration (ce qui fonctionne bien, d'ailleurs) et configurez Access pour créer un lien vers ces tables via ODBC.

Jusqu'à présent, j'ai rencontré les éléments suivants :

• Vous ne pouvez pas insérer/mettre à jour/supprimer des lignes dans une table sans clé primaire (pas de surprise).
• Les champs AutoNumber dans MS Access doivent être la clé primaire, sinon ils finiront simplement sous forme de colonnes entières dans MySQL (bien sûr, pourquoi ne serait-ce pas le PK ?)
• Les tables ont été migrées vers le type de table InnoDB de MySQL, mais les relations Access ne sont pas devenues des contraintes de clé étrangère MySQL.

Une fois la base de données utilisée, puis-je m’attendre à d’autres problèmes ?Surtout lorsque les deux utilisateurs travaillent dans la même table ?

Answer 1

J'avais une application qui fonctionnait de la même manière :une interface MS Access vers un backend MySQL.C'était tellement pénible que j'ai fini par écrire une interface Win32 à la place.Du haut de ma tête, j'ai rencontré les problèmes suivants :

• Le développement du lien ODBC semble avoir cessé depuis longtemps.Il existe différentes versions qui circulent --- très déroutantes.Le lien ODBC ne prend pas en charge Unicode/UTF8, et je me souviens qu'il y avait également d'autres problèmes (bien que certains puissent être résolus par une configuration minutieuse).
• Vous souhaiterez probablement modifier manuellement votre schéma de base de données pour le rendre compatible avec MS Access.Je vois que vous avez déjà découvert les clés de substitution nécessaires (c'est-à-dire les clés primaires int) :-)
• Vous devez garder à l’esprit que vous devrez peut-être utiliser des requêtes directes pour effectuer des manipulations SQL plus sophistiquées de la base de données MySQL.
• Soyez prudent lorsque vous utilisez beaucoup de VBA, car cela a tendance à corrompre votre fichier frontal.Compresser régulièrement la base de données (en utilisant le menu principal, Outils | Utilitaires de base de données | Compresser et restaurer, ou quelque chose comme ça --- j'utilise la version néerlandaise) et créer beaucoup des sauvegardes sont nécessaires.
• L'accès a tendance à générer beaucoup de trafic réseau.Genre, des lots vraiment énormes.Je n'ai pas réussi à trouver une solution à cela.L’utilisation d’un moniteur réseau est recommandée si vous souhaitez garder un œil sur cela !
• Access insiste pour stocker les booléens sous la forme 0/-1.À mon humble avis, 0/+1 a plus de sens, et je pense que c'est également la façon par défaut de faire les choses dans MySQL.Ce n'est pas un gros problème, mais si vos cases à cocher ne fonctionnent pas, vous devez absolument cocher ceci.

Une alternative possible serait de placer le backend (avec les données) sur un lecteur partagé.Je me souviens que c'est bien documenté, également dans l'aide.Vous voudrez peut-être jeter un oeil à quelques conseils généraux sur la séparation en frontend et backend et code qui se reconnecte automatiquement au backend au démarrage;Je peux également vous envoyer d'autres exemples de code ou le publier ici.

Sinon, vous pouvez également envisager MS SQL.Je n'ai aucune expérience avec cela, mais je suppose que cela fonctionne beaucoup mieux avec MS Access !

Answer 2

Je sais que ce sujet n'est pas trop récent, mais juste quelques explications supplémentaires :

Si vous souhaitez utiliser MS Access efficacement, en particulier avec des bases de données multi-utilisateurs plus volumineuses, procédez comme suit :

• divisez votre MDB en fichiers d'application frontale et backend (données uniquement) - vous aurez alors deux fichiers MDB distincts.

• migrez toutes les tables avec les données et la structure vers une base de données externe.Ça peut être:MySQL (fonctionne très bien, aucune limitation de taille de base de données, nécessite quelques compétences supplémentaires car ce n'est pas une technologie MS, mais c'est un bon choix dans de nombreux cas - de plus, vous pouvez faire évoluer votre backend avec plus de RAM et de processeurs supplémentaires, donc tout dépend de vos besoins et capacités matérielles) ;Oracle (si vous avez suffisamment d'argent ou une sorte de licence d'entreprise) ou Oracle 10g XE (si ce n'est pas un problème, que la taille de la base de données est limitée à 4 Go et qu'elle utilisera toujours 1 Go de RAM et 1 CPU), MS SQL Server 2008 (c'est une excellente paire d'avoir le frontend MS Access et le backend MS SQL Server dans tous les cas, mais vous devez payer la licence !- les avantages sont :intégration étroite, les deux technologies proviennent du même fournisseur ;MS SQL Server est très facile à maintenir et efficace en même temps) ou en édition Express (même histoire qu'avec Oracle XE - presque les mêmes limitations).

• Reliez votre interface MS Access à la base de données principale.Si vous avez sélectionné MS SQL Server pour le backend, ce sera aussi simple que d'utiliser l'assistant de MS Access.Pour MySQL, vous devez utiliser des pilotes ODBC (c'est simple et fonctionne très bien).Pour Oracle, veuillez ne pas utiliser les pilotes ODBC de Microsoft.Ceux d'Oracle feront bien mieux leur travail (vous pouvez comparer le temps nécessaire pour exécuter la requête SQL de MS Access vers Oracle via les pilotes Oracle ODBC et MS Oracle ODBC).À ce stade, vous disposerez d'un backend de base de données solide et d'un frontend MS Access entièrement fonctionnel - fichier MDB.

• compilez votre interface MDB en MDE - cela vous donnera beaucoup de vitesse.De plus, c'est la seule forme raisonnable de distribution de l'application MS Access à vos utilisateurs finaux.

• pour le travail quotidien - utilisez le fichier MDE avec l'interface MS Access.Pour le développement ultérieur du frontend MS Access, utilisez le fichier MDB.

• n'utilisez pas de composants ActiveX mal écrits pour améliorer les capacités de l'interface MS Access.Mieux vaut les écrire vous-même ou acheter les bons.

• ne croyez pas aux mythes selon lesquels il y a beaucoup de problèmes avec MS Access - c'est un excellent produit qui peut aider dans de nombreuses occasions.Le problème est que beaucoup de gens pensent que c'est un jouet ou que MS Access est généralement simple.Habituellement, ils génèrent beaucoup d’erreurs et de problèmes par eux-mêmes et par leur manque de connaissances et d’expérience.Pour réussir avec MS Access, il est important de comprendre cet outil - c'est la même règle, comme avec toute autre technologie.

Je peux vous dire que j'utilise MS Access assez avancé avec le backend MySQL et je suis très satisfait (en tant que développeur qui maintient cette application).Mes amis, les utilisateurs sont également satisfaits car ils se sentent très à l'aise avec l'interface graphique (frontend), la vitesse (MySQL), ils n'ont aucun problème avec le verrouillage des enregistrements ou les performances de la base de données.

De plus, il est important de lire beaucoup sur les bonnes pratiques et les expériences d'autres personnes.Je dirais que dans de nombreux cas, MS Access est une bonne solution.Je connais beaucoup de systèmes dédiés et personnalisés qui ont commencé comme une expérience sous la forme d'une base de données MS Access privée (fichier MDB) et ont ensuite évolué vers :MS Access divisé (MDE - frontend, MDB - backend) et enfin à :Frontend MS Access (MDE) et backend de bases de données "sérieuses" (principalement MS SQL Server et MySQL).Il est également important que vous puissiez toujours utiliser votre solution MS Access comme prototype fonctionnel : vous êtes prêt à utiliser le backend dans votre base de données (MySQL - supposons) et vous pouvez réécrire le frontend avec la technologie de votre choix (solution Web ?peut-être une application de bureau C# - ce dont vous avez besoin !).

J'espère avoir aidé certains d'entre vous à envisager de travailler avec MS Access.

Cordialement, Wawrzynhttp://dcserwis.pl

Answer 3

Gareth Simpson a déclaré :

S'il ne s'agit que de deux utilisateurs, l'accès doit très bien faire si vous mettez le .MDB sur un lecteur partagé.

Euh non.Il n’existe pas d’application Access multi-utilisateurs pour laquelle chaque utilisateur ne devrait pas disposer d’une copie dédiée du front-end.Cela signifie que chaque utilisateur doit avoir une MDB sur son poste de travail.Pourquoi?Parce que les objets frontaux ne se partagent pas bien (pas aussi bien que les tables de données Jet, bien qu'aucun d'entre eux dans ce scénario n'utilise MySQL comme back-end).

Gareth Simpson a poursuivi :

Je crois que les utilisateurs maximaux maximaux recommandés pour l'accès sont de 5, mais à l'occasion, je l'ai dépassé et je ne me décolle jamais.

Non, c'est complètement faux.La limite théorique pour les utilisateurs d'une MDB est de 255.Ce n'est bien sûr pas réaliste, car une fois que vous avez atteint environ 20 utilisateurs, vous devez programmer soigneusement votre application Access pour qu'elle fonctionne correctement (bien que les choses que vous devez faire dans une application Access-to-Jet soient les mêmes que celles que vous feriez). faire pour rendre toute application de base de données serveur efficace, par exemple, récupérer les plus petits ensembles de données utilisables).

Dans ce cas, puisque chaque utilisateur doit disposer d'une copie individuelle de la MDB frontale, les limites multi-utilisateurs d'Access/Jet ne sont tout simplement pas pertinentes du tout.

Answer 4

Je sais que cela ne répond pas directement à votre question, mais cela vaut peut-être la peine de consulter le Outil de migration SQL Server 2005 pour Access.Je n'ai jamais utilisé cet outil, mais cela pourrait valoir la peine de l'utiliser avec SQL Server 2005 Express Edition pour voir s'il y a les mêmes problèmes qu'avec MySQL.

Answer 5

N'oubliez pas de mettre un horodatage sur chaque enregistrement.parfois, ms access pensera « un autre utilisateur a modifié ou supprimé l'enregistrement » et ne vous permettra pas d'effectuer une modification !J'ai découvert cela à mes dépens.

Answer 6

En général, ça dépend :)

Je n'ai pas eu beaucoup de problèmes lorsque le côté application venait juste de mettre à jour les données via les formulaires.Vous pouvez recevoir des avertissements/erreurs lorsque la même ligne a été mise à jour par plusieurs utilisateurs ;mais Access semble constamment mettre à jour ses jeux d'enregistrements en direct.

Des problèmes peuvent survenir si Alice travaille déjà avec l'enregistrement 365 et que Bob le met à jour, puis qu'Alice essaie de le mettre à jour avec ses modifications.Si je me souviens bien, Alice recevra un message d'erreur énigmatique.Il serait plus facile pour les utilisateurs de détecter ces erreurs et de leur envoyer au moins un message d'erreur plus convivial.

J'ai eu plus de problèmes lorsque je modifiais des enregistrements dans le code VB via RecordSets, en particulier lorsqu'ils étaient combinés avec la modification des mêmes données sur des formulaires.Ce n'est pas nécessairement un problème multi-utilisateurs ;cependant, vous vous trouvez presque dans la même situation car vous avez un utilisateur avec plusieurs connexions aux mêmes données.

Answer 7

S'il ne s'agit que de deux utilisateurs, Access devrait fonctionner correctement si vous placez le .mdb sur un lecteur partagé.

L'avez-vous d'abord essayé plutôt que de simplement supposer que ce sera un problème.

Je crois que le nombre maximum d'utilisateurs simultanés recommandé pour Access est de 5, mais il arrive parfois que je l'ai dépassé et que je ne me détache jamais.

D'un autre côté, j'ai déjà utilisé Access comme frontal pour MySQL dans un environnement mono-utilisateur (moi).Ce fut une expérience singulièrement désagréable, je ne peux pas imaginer que cela deviendrait plus agréable avec deux utilisateurs.