MS Access front-end: Quels sont les risques?

Question

Je considère la construction d'un frontal MS Access pour une base de données Oracle.

Je ne suis pas un développeur (je suis un employé des travaux publics), mais je connais MS Access et Oracle. Le nombre d'utilisateurs serait de 5, pouvant atteindre 10-20. Le début serait principalement des rapports, avec la forme étrange pour la saisie de données. La sécurité n'est pas une préoccupation principale; c'est géré par la base de données, et l'information n'est pas sensible.

Je suis conscient du fait que les projets MS Access finissent souvent par être monstruosités désastreux. Pour autant que je sache, MS Access n'est pas destiné à être un système d'entreprise.

Pourtant je le considère, parce que, eh bien, je n'ai pas d'autres options. Je ne suis pas en I.T., et mon I.T. département n'a tout simplement pas les ressources pour aider. Et dans mon organisation, un système approprié, d'entreprise, prêt à l'emploi est prévu dans 5 à 10 ans. Je ne peux pas attendre aussi longtemps. Au lieu de cela, j'ai MS Access pour travailler avec. J'espère que si je m'en tiens à quelques principes clés, le système frontal ne sera pas une monstruosité fragile et désastreuse, mais plutôt un système durable et robuste.

J'espère:

• Gardez aussi simple qu'il est humainement possible. Si la fonctionnalité n'est pas absolument nécessaire, ne l'implémentez pas. Forcer les parties prenantes à justifier leurs demandes. Considérez-le uniquement comme un prototype et non comme un système d'entreprise formel. Faites jurer solennellement à toutes les parties prenantes de le migrer vers un système d'entreprise approprié.
• Configurez, ne personnalisez pas. Seulement personnaliser (VBA) comme dernier recours absolu. Même alors, pensez à ne pas faire les choses, avant de recourir à la personnalisation. Je dis cela, parce que je suis le seul au bureau qui sait comment écrire, et je ne suis même pas très bon.
• Tenez des «exercices d'incendie» réguliers. Si ça casse, et que je ne suis pas là pour t'aider, que va-t-il se passer? Tenez régulièrement des séances de formation et de partage des connaissances pour informer les collègues du système.
• Tendez au système comme si je m'occupais d'un jardin. Restez au top des choses. Améliorer en permanence en le rendant plus simple, plus efficace, et supprimer les fonctionnalités inutiles.

---

Avec tout cela dit, même si je parviens à faire ces choses, je suppose qu'il ya encore des problèmes liés à faire un système d'entreprise dans MS Access.

Quels sont les risques et les problèmes inhérents associés à un frontal d'entreprise MS-Access?

Answer 1

Tout d'abord, vous devriez vous féliciter! Vous n'avez certainement pas l'air inexpérimenté; bien au contraire. Votre approche de la construction et de l'entretien d'un système sonne de tout premier ordre. En ce qui concerne votre limitation, il semble que vous ayez besoin d'un outil de reporting, et il semble que Access soit votre seule option. Je sais qu'il y a un commentaire ici qui suggère Oracle Apex, mais je suppose que ce n'est pas une option pour vous. Un produit utilisant des méthodes d'accès natif à Oracle fonctionnerait très certainement mieux que Access, mais cela ne signifie pas que vous avez atteint une impasse. L'accès est un outil puissant si vous comprenez ses limites (et par là, je ne parle pas seulement de la limite de taille de fichier de 2 Go, je doute que vous y arriviez).Voici quelques suggestions que je peux vous proposer, et j'espère que cela ne vous semble pas étranger:

1. Si vous avez la possibilité d'écrire votre SQL en tant que procédures ou vues stockées dans Oracle, faites-le.
2. Ne pas lier à des tables dans Oracle, ce qui sera douloureusement lent.
3. N'utilisez pas ADO pour transférer des données d'Oracle à Access, qui sera également lent, car il nécessitera une gestion ligne par ligne.
4. Utilisez les requêtes SQL directes pour vous connecter à Oracle et exécuter vos procédures/vues/SQL stockées. Ce sera votre option la plus rapide, car Access envoie uniquement votre requête au serveur à exécuter; il ne fait rien lui-même pour l'exécuter (ou estimer comment l'exécuter). Essayez d'exécuter toute votre logique au sein d'Oracle. Cela signifie que si vous n'avez pas la possibilité d'écrire des procédures stockées et que vous devez créer des tables temporaires, faites-le dans la session Oracle ou dans le script SQL que vous exécutez via la requête SQL directe.
5. Si vous besoin de pour transférer des données à l'accès, essayez de limiter. Vous n'êtes probablement pas en train de créer un rapport de 200 pages, alors ne renvoyez pas les données dont vous n'avez pas besoin. utiliser la puissance de traitement du serveur à votre avantage. Supposons que vous ayez fait tout cela, et que vous soyez maintenant prêt à distribuer le fichier Access.
6. Ne placez pas la base de données sur un lecteur réseau et partagez-la avec les utilisateurs. Donnez à chaque utilisateur sa propre copie. Maintenant, ce sujet en lui-même serait une longue discussion, car des choses comme le contrôle de version entrent en jeu, mais je n'entrerai pas dans le sujet ici. Si les utilisateurs peuvent toujours accéder à un site Web et télécharger un fichier Access propre chaque fois qu'ils doivent l'utiliser, faites-le. Si ce n'est pas le cas, et qu'ils lancent toujours leur copie locale, vous devez implémenter des routines de nettoyage de toutes les données locales dans Access, puis activer le paramètre compact-on-close, afin de supprimer l'encombrement qui pourrait affecter les performances.
7. Si vos requêtes contre Oracle ne fonctionnent pas correctement et que vos rapports finissent par être lents, n'ayez pas peur de demander de l'aide. Les administrateurs de base de données n'aimeront pas ce que vous ferez qui affectera les performances de leur base de données, alors utilisez-les pour vous aider à optimiser votre SQL.