Comment migreriez-vous des centaines de bases de données MS Access vers un service central?

Nous avons littéralement des centaines de bases de données Access flottant sur le réseau. Certains avec une utilisation légère et certains avec une utilisation assez lourde, et certains pas d'utilisation que ce soit. Ce que nous aimerions faire, c'est centraliser ces bases de données sur une database gérée et conserver autant que possible les rapports et les formulaires qui s'y trouvent.

Les avantages de faire cela serait d'avoir un certain type de suivi de l'utilisation, et aussi la capacité de prêter plus d'attention à certaines des données décentralisées importantes qui sont stockées dans ces applications.

Il n'y a aucune contrainte réelle sur le SGBDR (Oracle, server MS SQL) ou la stack sur laquelle il fonctionnerait (LAMP, ASP.net, Java) et il n'y aura évidemment pas de solution miracle pour cela. Nous aimerions quelque chose qui peut supprimer le travail de grognement initial d'une manière automatisée.

La migration d'une application Access n'est pas une solution miracle. Il se peut que certaines choses soient plus rapides, mais certains types d'opérations seront de vrais chiens. Cela signifie qu'une application migrée doit être testée de manière approfondie et que les goulets d'étranglement de performance doivent être traités, généralement en déplaçant la logique de récupération de données côté server (vues, procédures stockées, requêtes passthrough).

Ce n'est pas vraiment une réponse à la question, cependant.

Je ne pense pas qu'il y ait une réponse automatique au problème. En effet, je dirais que c'est un problème de personnes et pas un problème de programmation du tout. Quelqu'un doit examiner le réseau et déterminer la propriété de toutes les bases de données Access, puis interroger les users pour savoir ce qui est utilisé et ce qui ne l'est pas. Ensuite, chaque application doit être évaluée pour savoir si elle doit ou non être repliée dans un magasin de données ou une application à l'échelle de l'entreprise, ou si son implémentation initiale en tant que petite application pour quelques users était la meilleure approche.

Ce n'est pas la réponse que vous voulez entendre, mais c'est la bonne réponse précisément parce que c'est un problème de personnel / gestion, pas une tâche de programmation.

Nous migrons (soit en utilisant l'assistant de migration, soit à la main) vers le server SQL. C'est généralement assez simple. Remplacez toutes les tables d'access par des tables liées au server sql et conservez tous les formulaires / rapports / macros en access. L'investissement dans l'access n'est pas perdu et les users peuvent continuer à travailler comme d'habitude. Vous obtenez la fiabilité du server sql et des sauvegardes centralisées. Gardez à l'esprit – nous l'avons fait pour quelques grandes bases de données d'access, pas des centaines. Je ferais un pilote de quelques douzaines et voir comment cela fonctionne.

MISE À JOUR: Je viens de find cela, l'assistant de migration du server sql, ça pourrait valoir le coup d'oeil: http://www.microsoft.com/sql/solutions/migration/default.mspx

Mise à jour: Oui, un refactoring sera nécessaire pour les bases de données mal conçues. Quant à la façon de gérer l'étalement de l'access? Je l'ai rencontré dans les entresockets avec beaucoup d'users techniques (ingénieurs surtout, sont les pires pour cela … et Excel). Nous avons fait une vérification – (après avoir sauvegardé) supprimé toutes les bases de données qui n'avaient pas été touchées depuis plus d'un an. Les "propriétaires" ont été atsortingbués en fonction de l'location et / ou des données dans la database. Si la database était dans "S: \ quality \ test_dept", le responsable de la qualité et l'ingénieur de test de la tête devaient s'en charger ou nous l'effacions (à nouveau après l'avoir sauvegardé).

Oracle dispose d'un workbench de migration pour le port de systèmes MS Access vers Oracle Application Express, ce qui mérite d'être étudié.

http://apex.oracle.com

Alors? Dédiez un server à vos bases de données Access.

Désormais, vous bénéficiez d'un certain type de suivi de l'utilisation et de la possibilité d'accorder plus d'attention à certaines des données décentralisées importantes stockées dans ces applications.

C'est ce que vous alliez faire de toute façon, seulement vous vouliez utiliser un moteur de database différent au lieu de NTFS.

Et maintenant vous devez forcer les users sur votre server.

Eh bien, vous pouvez les encourager en leur disant que vous n'allez plus écraser leurs données avec d'anciennes sauvegardes, car maintenant vous possédez datatables, et vous ne le ferez plus.

De plus, vous pouvez leur dire que leurs applications vont s'exécuter plus rapidement maintenant, car vous allez exclure le dossier de l'parsing antivirus à l'access (vous ne le faites pas pour vos autres bases de données, c'est pourquoi ils sont pleins de SQL malware, mais ces bases de données ne seront pas exposées à Internet), et prévoyant de désactiver la signature de packages (vous n'en aurez pas besoin sur un server dédié: uniquement pour les personnes qui partagent leur partage de files sur leur server de domaine) .

Mise à niveau facile, amélioration du service aux users, plus grande centralisation et contrôle de l'informatique. Tout le monde est gagnant.

Suite aux commentaires de David Fenton

Votre règle administrative sera quelque chose comme ceci:

Si datatables contenues dans la database ne sont utilisées que par un user, pour son propre travail (seul), elles peuvent le conserver dans son propre partage réseau.

Si datatables contenues dans la database doivent être utilisées par plusieurs personnes (même si elles ne sont que deux), cette database doit être placée sur un server central et sous gestion informatique (sauvegardes, changements de schéma, interfaces, etc. ). C'est parce que, quelqu'un d'expérimenté doit coordonner l'set du spectacle ou nous risquerons le time / ressources de l'homme suivant sur toute la ligne.