Comment migrer de MS Access vers le serveur SQL 2005?

Question

J'ai une application Windows VB.NET qui extrait des informations d'une base de données MS Access. Le rôle principal de l'application est d'extraire des informations à partir de fichiers Excel dans différents formats, de standardiser la mise en page du fichier et de l'écrire dans les fichiers csv. L'application utilise MS Access comme source pour les clés et les fichiers de références croisées.

L'application Windows utilise des jeux de données typés pour une grande partie de l'interaction de l'utilisateur entre la base de données. La normalisation est effectuée sur la machine de chaque client. L'application n'est pas ... comment puis-je dire ceci ... FAST :-). Question: Quelle est la meilleure façon de migrer la base de données et l'application vers SQL Server 2005. Je pense que ce serait une bonne idée d'écrire le code pour les paquetages de standarization in et SSIS.

Quelle est la manière appropriée de procéder à cette migration?

---

L'application extrait les données de 250 fichiers Excel chaque semaine et approximatley 800 fichiers chaque mois avec une moyenne d'environ 5000 lignes par fichier. Il existe 13 formats de fichiers différents qui sont standardisés et mis en 3 formats standard différents. L'application prend entre 25 min. et 40 min à courir en fonction de la course de données dont nous parlons. 95% de l'application est le processus de standarisation. Tout ce que fait l'utilisateur est de choisir quelques paramètres puis de commencer la course.

Answer 1

Microsoft fournit un free tool pour migrer une base de données Access vers SQL Server. Une fois que vous avez mis à niveau, vous devriez être en mesure de changer votre chaîne de connexion pour pointer vers SQL Server.

Answer 2

Vous pouvez exécuter votre application via un profileur pour vous assurer que la base de données Access est vraiment ce qui ralentit votre application, et pas autre chose. Il serait dommage de faire tout le travail pour le convertir en serveur SQL, et n'avoir rien à montrer pour cela.

Answer 3

L'assistant de migration d'accès peut être utilisé comme point de départ.

Vous pouvez être en mesure de modifier le serveur SQL Server avec des tables liées dans Access sans modifier votre frontal. Ensuite, vous pouvez modifier le frontal pour aller directement à SQL Server à volonté.

Sauf si vous frappez très fortement Access, je doute que ce soit votre goulot d'étranglement. En ce qui concerne la lecture des fichiers Excel, SSIS peut le faire, mais il n'est peut-être pas aussi fiable que le mécanisme que vous utilisez actuellement dans VB.NET, si votre code VB.NET a beaucoup de logique intelligente. gérer un certain degré de variation dans les fichiers d'entrée

En ce qui concerne l'écriture de données au format CSV, SSIS fonctionne correctement et j'ai trouvé SSIS assez performant. Si vous pouviez donner plus de détails sur le flux de travail et sur l'interaction de l'utilisateur avec la base de données par rapport à la configuration du programme, il pourrait être plus facile de vous aider avec votre architecture. SSIS est très configurable à la volée (le package se configurant lui-même pendant qu'il fonctionne), et dans de nombreux cas, il peut être programmé pour lire divers fichiers Excel et les convertir en CSV, mais il n'est pas aussi configurable sur le serveur. voler comme un système codé à la main. Il est également possible d'utiliser le modèle d'objet SSIS pour générer des packages par programme, puis de les exécuter. Cela ne présente pas certaines des limitations d'un package qui se configure lui-même, mais le modèle d'objet est plutôt complexe.

Answer 4

Veiller à ce que la portée est claire:

1. Utilisez un programme .NET pour
2. conduire un frontal de base de données Access qui vous permet de
3. Extraire des données à partir d'un certain nombre de feuilles de calcul Excel,
4. Masser les données de façon appropriée et
5. Enregistrer le résultat dans un fichier CSV.

Quels types de volumes parlons-nous? Combien de clients, combien de feuilles de calcul par client, combien de lignes par feuille de calcul (je pense que ce serait 32767 max pour une seule feuille de calcul, n'est-ce pas?)

On dirait beaucoup de pièces mobiles Et Access est généralement un très bon outil (avec VBA) pour faire ce genre de chose par lui-même

Il ne semble pas assez de volume pour fournir un délai important pour une base de données Access bien conçue Excel pour accomplir tout le processus en utilisant VBA. Si votre alternative implique l'installation et exploitation SQL Server (à la place d'accès) sur chaque client, je serais surpris si l'administration et les frais généraux de fonctionnement n'augmente pas.

Answer 5

So Weekly, par client: 250 fichiers à 25 minutes = 10 fichiers/minute ou 6 secondes par fichier.

Mensuel, par client: 800 fichiers à 40 minutes = 20 fichiers/minute ou 3 secondes par fichier.

Mes attentes seraient inférieures à 1 sec. par fichier (5000 lignes) aller-retour comprenant:
a. Importer ou attacher xls à mdb,
b. Transformer via Access SQL
c. Exporter vers csv

La seule explication qui vient à l'esprit est que peut-être l'application .NET est en train de lire, la transformation, et l'enregistrement d'une ligne à la fois. Est-ce possible?

Si vous convertissez à SSIS, alors que probablement l'application démode .NET, parce que SSIS voudra gérer l'ETL (et sauvegarder) lui-même. Donc, vous allez essentiellement réécrire le logiciel. Mais vous pouvez avoir de meilleures ressources pour SSIS que pour Access. Mais il me semble que c'est exagéré. BUt alors .NET plutôt que VBA est peut-être aussi exagéré; et réécrire dans VBA est aussi un travail. Le moindre effort serait de voir si vous pouvez faire tout le ETL (et sauvegarder) en utilisant Access SQL pour la plupart, et en utilisant VBA juste pour le script, pour parcourir les fichiers d'entrée dans un répertoire ou autre.

Je pense que vous pourriez au moins prototyper les cas d'utilisation de base et savoir si vous pouvez savoir assez rapidement où le temps est dépensé maintenant (comme suggéré par les réponses précédentes.) Mais cela vaut la peine d'être découvert avant d'entreprendre le réaménagement ressources destinées à la mauvaise partie du problème. Si vous pouvez développer un peu dans ces domaines, je pourrais probablement vous diriger plus loin. Mais Access est assez bien adapté pour ce genre de chose, à (IMHO) un TCO inférieur à celui de SQL Server + SSIS + .NET. Sans parler que je serais surpris

si les fichiers csv sont le véritable point final, qui peut jouer un rôle dans la décision. Les données Excel ne finissent-elles pas vraiment plus bas sur le chemin?Enfin, à quel point un processus de 25 à 40 minutes est-il inacceptable, peut-il être interrompu pendant la pause déjeuner, et peut-être fonctionne-t-il normalement?

---

Notes:

 
Per week  

Excel Files 250 
Minutes 25 
Minutes/File 0.1 
Sec/File 6 


Per month 

Excel files 800 
Minutes 40 
Minutes/File 0.05 
Sec/File 3