Ad-hoc forbindelsesstrenge og heterogene forespørgsler til MS Access
Heterogene forespørgsler er grunden til, at forbindelsesstrenge, især ad-hoc-forbindelsesstrenge, er vigtige. I tidligere artikler i serien så du, hvordan du kunne tilpasse forbindelsesparametrene til at oprette forbindelse til Excel og tekstfiler. I tilfælde af tekstfiler kan du også beskrive skemaet for tekstfilens struktur ved at bruge enten schema.ini eller gemte specifikationer. I den første artikel lærte du også forskellen mellem at linke og åbne en datakilde.
Heterogene forespørgsler i stedet for VBA-kode
Du så i de tidligere artikler eksempelkode for åbning af en sådan datakilde ved hjælp af DAO's OpenDatabase metode.
Set db = DBEngine.OpenDatabase(vbNullString, False, False, "Excel 12.0 Xml;HDR=YES;IMEX=2;ACCDB=YES;DATABASE=C:\Links\Products.xlsx")
Dette kan efterlade dig med det indtryk, at den eneste måde at åbne en datakilde på er via kode. Men det behøver ikke være tilfældet! Du kan faktisk åbne en vilkårlig datakilde ved kun at bruge Access-forespørgsel. Her er en eksempelsyntaks, du kan køre i en Access-forespørgsel:
SELECT * FROM [Excel 12.0 Xml;HDR=YES;IMEX=2;ACCDB=YES;DATABASE=C:\Links\Products.xlsx].[Sheet1$];
Generelt set er forbindelsesstrengen du sætter i OpenDatabase 's 4. parameter er den, du vil præfiksere "tabellen" med. Derfor vil den generelle syntaks være:
FROM [<complete connection string>].[<name of the table>]
Du kan bruge OpenDatabase metode og iterer over TableDefs for at finde de gyldige navne på tabellen. Du kan så bruge det til at udfylde 2. del af navnet.
Hvorfor åbne i stedet for link?
En fordel ved at åbne i modsætning til at linke er, at du kan ændre forbindelsesstrengen under kørsel. Du behøver heller ikke beskæftige dig med den nødvendige oprydning, såsom sletning af de ikke-længere nødvendige linkede objekter. Det er rent forbigående, hvilket ville være perfekt til at flytte data fra én kilde til en anden kilde uden at skrive nogen VBA-kode.
Her er et muligt scenarie. Antag, at vi vil oprette tekstfiler, der er et output fra en visning på vores SQL Server-database. Du så fra tidligere artikler, at vi kunne skrive VBA-kode til at sløjfe over DAO-postsættene og skrive indholdet en efter en. Men som et alternativ kan vi bare i stedet oprette en Access-forespørgsel med denne 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];
Fordi både destinationen og kilden ikke er Access' kilde, er det det, vi kalder "heterogen forespørgsel". Bemærk, at selvom vwProducts var en sammenkædet tabel, ville det stadig være en "heterogen" forespørgsel. Det skyldes, at vi stadig blander forskellige datakilder i en enkelt forespørgsel.
Endnu vigtigere, ved at bruge en heterogen forespørgsel, undgår vi behovet for at oprette midlertidige objekter i vores Access-applikation. Oprettelse af et midlertidigt objekt kan få Access-applikationen til at blæse op. Dette er tilfældet selv ved import eller ved at linke eller ved at bruge recordsets i VBA. En oppustet fil kan til gengæld kræve komprimering og reparation. Men når du bruger en heterogen forespørgsel til direkte at overføre data fra en datakilde til en anden, undgår du al den oppustethed. Derfor gør den den ideel til scenarier, hvor din Access-applikation skal generere flere filer uden vedligeholdelse på selve applikationen.
Konstruktion af ad-hoc-forbindelsesstrengen
Nu kan du se, hvorfor det er værdifuldt at forstå de parametre, der bruges i forbindelsesstrengen. Det er især vigtigt at kontrollere destinationen (f.eks. stien til tekstfiler eller rækkevidden for Excel-ark). Med disse ikke-relationelle datakilder er det muligvis ikke intuitivt, hvad der udgør en "database" og "tabeller" i en sådan datakilde. Du kan bruge de sidste 3 artikler som reference for at få hjælp til at konstruere forbindelsesstrengen og skemaoplysningerne for at sikre, at layoutet kommer rigtigt ud. Når det er sagt, er der også en genvej, du kan bruge til at hjælpe dig med at finde forbindelsesstrengen.
Du kan bruge fanen Ekstern og enten "Importér tekst" eller Importer Excel" og vælge linkindstillingen. Det er normalt den tredje mulighed i guiden som vist.
Når du har gennemgået guiden og gemt den nye sammenkædede tabel, kan du derefter inspicere forbindelsesstrengen via VBA-vinduet med denne kode:
?CurrentDb.TableDefs("<name of linked table>").Connect Dette kan give dig tip til, hvordan du konstruerer forbindelsesstrengen, og du kan derefter tilpasse. Det meste af tiden vil du finde dig selv i at tilpasse stien eller tabelnavnet, så det normalt fungerer nok som en teknik under din udvikling. Du kan derefter oprette en heterogen forespørgsel i overensstemmelse hermed og slette den sammenkædede tabel.
Konklusioner
I serien lærte du forskellen på at linke og åbne. Du så, hvordan Excel- og tekstfiler kan bruges, som om de var en DAO.Database objekter med "tabeller". Med den 2. artikel lærte du om forbindelsesparametre for en Excel-projektmappe. I den tredje artikel så du behovet for at have skemaoplysninger til at beskrive en tekstfil. Den 4. artikel beskrev, hvordan man bruger schema.ini . I den 5. artikel så du, hvordan MSysIMEXSpecs og MSysIMEXColumns kan bruges som en alternativ til schema.ini metode.
Til sidst sætter vi det hele sammen i at konstruere en heterogen forespørgsel som et eksempel på en lavkodeløsning. Vi behøver ikke at skrive store mængder VBA-kode bare for at skubbe data fra en kilde til en anden kilde. Jeg tror, du er enig i, at det er langt nemmere at ændre en Access-forespørgsel ved at justere stien eller tabelnavnet, end det er at skrive store og komplekse VBA-rutiner til at læse og skrive data. Endnu vigtigere ved at bruge en heterogen forespørgsel, bliver det meget nemmere at håndtere ændringerne i strukturen på begge sider. Tilføjet en ny kolonne? Intet problem, bare føj den nye kolonne til forespørgslen, så er vi færdige.
Men som du kan se, kræver dette en god forståelse af forbindelsesstrengens konstruktion. Af den grund var det nødvendigt at studere forviklingerne i forbindelsesstrengen i dybden, som vi gjorde fra 2. til 5. artikel. Selvom vi kan bruge den linkede tabel-guide til at give os et tip om forbindelsesstrengene. Men det er kun antydninger. Derfor er det godt at vide, hvordan man præcist styrer outputtet. Jeg håber, du er enig i, at en indsats for at forstå, hvordan forbindelsesstrenge fungerer, vil betale sig selv i sparet arbejdskraft.