Obtenir des données mixtes tabulaires et non tabulaires d'Excel dans Access

Question

Ma programmation Access est un peu rouillée, & Je n'ai jamais travaillé avec autant de fichiers Excel. J'ai besoin d'importer des données de feuilles de calcul Excel dans Access 2007. Ces feuilles de calcul ont un format fixe (prévisible), mais elle comprend une «zone d'en-tête» où je dois lire des éléments de données uniques à partir de cellules spécifiques, suivi par une masse de données tabulaires (~ 500 lignes dans l'échantillon que j'ai vu jusqu'ici). Je vais traiter tout cela dans un ensemble de tables qui sont normalisées différemment de la mise en page plate de la feuille de calcul.

Je sais comment ouvrir un jeu d'enregistrements ADO sur les données tabulaires, et il devrait fonctionner assez bien pour mes fins. Je suppose également que je peux référencer le modèle d'objet Excel et ouvrir les feuilles via Automation pour obtenir les éléments de données "zone d'en-tête". Ma question est la suivante: puisque je dois (je pense) utiliser l'approche d'automatisation pour la "zone d'en-tête", je ferais mieux de le laisser ouvert dans ce mode pour passer aux données tabulaires (avec cellule/plage de navigation), ou la fermeture de ce mode & allant à ADO? Je pense que c'est le dernier - et je serais plus à l'aise avec - mais je ne veux pas faire la mauvaise chose juste parce que c'est plus familier.

Modifier Il semble que je n'étais pas clair que je dois construire cette capacité dans la « application », comme quelque chose qu'un utilisateur peut répéter la ligne. Je suis assuré que je peux faire confiance au format de la feuille de calcul (même si j'inclurai le trapping d'erreur pour l'échec gracieux si cela s'avère faux). Ces feuilles de calcul sont des «documents de conception officiels» pour le matériel, et mon application doit gérer les nouveaux éléments &/mis à jour pour suivre les éléments décrits dans les tableaux sous des formes que le format Excel plat ne permet pas.

Answer 1

Parmi ces deux options, je choisirais la seconde simplement parce que je trouve plus pratique de travailler avec un jeu d'enregistrements ADO. Cela devrait être assez simple si vous pouvez assigner une plage nommée aux données tabulaires de votre feuille de calcul.

Modifier: Si votre feuille de calcul comprend les noms de champs, l'approche recordset serait moins enclin à se briser en raison des changements de tableurs comme une ou plusieurs nouvelles colonnes insérées avant ou entre les colonnes existantes ou une réorganisation de l'existant colonnes.

Mais en fait, je pense que le TransferSpreadsheet Method pourrait être plus pratique. Vous pouvez spécifier la plage de feuille de calcul comme une plage nommée ou par adresse de cellule comme dans cet exemple de la page liée:

DoCmd.TransferSpreadsheet acImport, 3, _ 
    "Employees","C:\Lotus\Newemps.wk3", True, "A1:G12" 

En outre, vous pouvez choisir entre importer la feuille de calcul gamme directement dans une table d'accès, ou un lien vers la gamme comme une table "virtuelle" ... celui qui répond le mieux aux besoins de votre application.

Edit2: Création d'un lien (acLink au lieu de acImport) avec TransferSpreadsheet vous permettra d'exécuter des instructions SQL sur la table de lien:

INSERT INTO DestinationTable (field1, field2, field3) 
SELECT foo, bar, bat FROM LinkedTable; 

Answer 2

Je ferais tout cela via l'automatisation. Pourquoi avoir deux processus séparés où l'on va faire? Après avoir lu les informations d'en-tête, les informations tabulaires seront assez faciles.

Answer 3

Je hérité une demande de retour à la mi-2000 qui a été construit pour importer des feuilles de calcul Excel qui rapportaient essentiellement la sortie de MYOB (un programme de comptabilité).Ce qui avait été fait était simplement de créer une table modèle qui avait toutes les colonnes nécessaires pour accueillir le rapport, en utilisant le type de données texte pour toutes les colonnes. Ensuite, les lignes non-données ont été filtrées et traitées dans la table de destination éventuelle.

Ce n'est pas élégant et ne nécessite pas beaucoup de programmation, bien que l'implémentation dont j'ai hérité utilise une table temporaire dédiée pour chaque mise en page de rapport importée. Vous pouvez facilement remplacer tous ceux avec une seule table avec 100 colonnes de texte de 255 (ou des champs mémo, d'ailleurs, si c'était une exigence), et juste le réutiliser.

Je ne suis pas sûr si je le recommanderais ou non, mais c'est vraiment très facile sans exiger beaucoup de code.

Answer 4

Si les informations d'en-tête est vraiment compliqué, cela peut simplifier votre travail de codage:

1. Dans le fichier Excel de conception officielle, créez un onglet caché.
2. Dans cet onglet, créez une table à 1 ligne qui se connecte à tous les éléments d'en-tête qui vous intéressent. (Par exemple, ligne 1 colonne 1 à "Document #" et ligne 2 colonne 1 à Feuille1: A1)
3. Vous pouvez ensuite réutiliser la même procédure VBA pour importer à la fois vos données tabulaires et vos données d'en-tête.