Access
 sql >> Base de données >  >> RDS >> Access

Chaînes de connexion ad hoc et requêtes hétérogènes pour MS Access

Chaînes de connexion ad hoc et requêtes hétérogènes pour MS Access

Les requêtes hétérogènes sont la raison pour laquelle les chaînes de connexion, en particulier les chaînes de connexion ad hoc, sont importantes. Dans les articles précédents de la série, vous avez vu comment personnaliser les paramètres de connexion pour vous connecter à Excel et aux fichiers texte. Dans le cas des fichiers texte, vous pouvez également décrire le schéma de la structure du fichier texte en utilisant soit schema.ini ou des spécifications enregistrées. Dans le premier article, vous avez également appris la différence entre lier et ouvrir une source de données.

Requêtes hétérogènes au lieu de code VBA

Vous avez vu dans les articles précédents un exemple de code d'ouverture d'une telle source de données en utilisant OpenDatabase du DAO méthode.

Set db = DBEngine.OpenDatabase(vbNullString, False, False, "Excel 12.0 Xml;HDR=YES;IMEX=2;ACCDB=YES;DATABASE=C:\Links\Products.xlsx")

Cela peut vous donner l'impression que la seule façon d'ouvrir une source de données est via le code. Mais cela ne doit pas être le cas ! Vous pouvez réellement ouvrir une source de données arbitraire en utilisant uniquement la requête Access. Voici un exemple de syntaxe que vous pouvez exécuter dans une requête Access :

SELECT * 
FROM [Excel 12.0 Xml;HDR=YES;IMEX=2;ACCDB=YES;DATABASE=C:\Links\Products.xlsx].[Sheet1$];

De manière générale, la chaîne de connexion que vous mettez dans le OpenDatabase Le 4ème paramètre est celui avec lequel vous préfixerez la "table". Par conséquent, la syntaxe générale serait :

FROM [<complete connection string>].[<name of the table>]

Vous pouvez utiliser le OpenDatabase méthode et itérer sur TableDefs pour trouver les noms valides de la table. Vous pouvez ensuite l'utiliser pour remplir la 2ème partie du nom.

Pourquoi ouvrir plutôt que lier ?

L'un des avantages de l'ouverture par opposition à la liaison est que vous pouvez modifier la chaîne de connexion au moment de l'exécution. Vous n'avez pas non plus à vous occuper du nettoyage requis, comme la suppression des objets liés dont vous n'avez plus besoin. C'est purement transitoire, ce qui serait parfait pour déplacer des données d'une source à une autre sans écrire de code VBA.

Voici un scénario possible. Supposons que nous voulions créer des fichiers texte qui sont une sortie d'une vue sur notre base de données SQL Server. Vous avez vu dans les articles précédents que nous pouvions écrire du code VBA pour boucler sur les jeux d'enregistrements DAO et écrire le contenu un par un. Cependant, comme alternative, nous pouvons simplement créer une requête Access avec ce SQL :

INSERT INTO [Text;DATABASE=C:\Links\].[products.csv;] (Products, Count)
SELECT Products, Count
FROM [ODBC;DRIVER=ODBC Driver 17 for SQL Server;SERVER=myServer;DATABASE=myDatabase;].[vwProducts];

Étant donné que la destination et la source ne sont pas la source d'Access, c'est ce que nous appelons une "requête hétérogène". Notez que même si le vwProducts était une table liée, il s'agirait toujours d'une requête "hétérogène". En effet, nous mélangeons toujours différentes sources de données dans une seule requête.

Plus important encore, en utilisant une requête hétérogène, nous évitons d'avoir à créer des objets temporaires dans notre application Access. La création d'un objet temporaire peut entraîner le gonflement de l'application Access. C'est le cas même avec l'importation ou en liant ou en utilisant des jeux d'enregistrements dans VBA. Un fichier gonflé peut à son tour nécessiter un compactage et une réparation. Cependant, lorsque vous utilisez une requête hétérogène pour transférer directement des données d'une source de données à une autre, vous évitez tout ce gonflement. Par conséquent, cela le rend idéal pour les scénarios où votre application Access doit générer plusieurs fichiers sans maintenance sur l'application elle-même.

Construire la chaîne de connexion ad hoc

À présent, vous pouvez voir pourquoi il est utile de comprendre les paramètres utilisés dans la chaîne de connexion. Il est particulièrement important de contrôler la destination (par exemple, le chemin pour les fichiers texte ou la plage pour la feuille Excel). Avec ces sources de données non relationnelles, ce qui constitue une "base de données" et des "tables" dans une telle source de données peut ne pas être intuitif. Vous pouvez utiliser les 3 derniers articles comme référence pour vous aider à construire la chaîne de connexion et les informations de schéma afin de vous assurer que la mise en page est correcte. Cela dit, il existe également un raccourci que vous pouvez utiliser pour vous aider à trouver la chaîne de connexion.

Vous pouvez utiliser l'onglet Externe et "Importer du texte" ou "Importer Excel" et choisir l'option de lien. Il s'agit généralement de la troisième option de l'assistant, comme indiqué.

Après avoir parcouru l'assistant et enregistré la nouvelle table liée, vous pouvez ensuite inspecter la chaîne de connexion via la fenêtre immédiate VBA avec ce code :

?CurrentDb.TableDefs("<name of linked table>").Connect

Cela peut vous fournir des conseils sur la façon de construire la chaîne de connexion et vous pouvez ensuite la personnaliser. La plupart du temps, vous vous retrouverez à personnaliser le chemin ou le nom de la table afin qu'il fonctionne généralement suffisamment comme technique lors de votre développement. Vous pouvez ensuite créer une requête hétérogène en conséquence et supprimer la table liée.

Conclusion

Dans la série, vous avez appris la différence entre lier et ouvrir. Vous avez ensuite vu comment les fichiers Excel et texte peuvent être utilisés comme s'il s'agissait d'une DAO.Database des objets avec des "tableaux". Avec le 2ème article, vous avez découvert les paramètres de connexion pour un classeur Excel. Dans le 3ème article, vous avez vu la nécessité d'avoir des informations de schéma pour décrire un fichier texte. Le 4ème article décrivait comment utiliser schema.ini . Dans le 5ème article, vous avez vu comment les MSysIMEXSpecs et MSysIMEXColumns peut être utilisé comme alternative au schema.ini méthode.

Enfin, nous mettons tout cela ensemble dans la construction d'une requête hétérogène comme exemple de solution low-code. Nous n'avons pas besoin d'écrire une grande quantité de code VBA juste pour pousser les données d'une source à une autre source. Je pense que vous conviendrez qu'il est beaucoup plus facile de modifier une requête Access en ajustant le chemin ou le nom de la table que d'écrire une routine VBA volumineuse et complexe pour lire et écrire des données. Plus important encore, en utilisant une requête hétérogène, il devient beaucoup plus facile de gérer les modifications de la structure de part et d'autre. Une nouvelle colonne ajoutée ? Pas de problème, ajoutez simplement la nouvelle colonne à la requête et nous avons terminé.

Cependant, comme vous le voyez, cela nécessite une bonne compréhension de la construction de la chaîne de connexion. Pour cette raison, il était nécessaire d'étudier en profondeur les subtilités de la chaîne de connexion comme nous l'avons fait du 2ème au 5ème articles. Bien que nous puissions utiliser l'assistant de table liée pour nous donner un indice sur les chaînes de connexion. Mais ce ne sont que des indices. Par conséquent, il est bon de savoir comment contrôler précisément la sortie. J'espère que vous conviendrez qu'investir des efforts pour comprendre le fonctionnement des chaînes de connexion se rentabilisera en économisant du travail.