sql >> Databasteknik >  >> RDS >> Access

Ad-hoc anslutningssträngar och heterogena frågor för MS Access

Ad-hoc anslutningssträngar och heterogena frågor för MS Access

Heterogena frågor är anledningen till att anslutningssträngar, särskilt ad-hoc-anslutningssträngar, är viktiga. I tidigare artiklar i serien såg du hur du kunde anpassa anslutningsparametrarna för att ansluta till Excel och textfiler. När det gäller textfiler kan du också beskriva schemat för textfilens struktur med antingen schema.ini eller sparade specifikationer. I den första artikeln lärde du dig också skillnaden mellan att länka och öppna en datakälla.

Heterogena frågor istället för VBA-kod

Du såg i de tidigare artiklarna exempelkod för att öppna en sådan datakälla med DAO:s OpenDatabase metod.

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

Detta kan ge dig intrycket att det enda sättet att öppna en datakälla är via kod. Men så behöver det inte vara! Du kan faktiskt öppna en godtycklig datakälla med endast Access-fråga. Här är ett exempel på syntax som du kan köra i en Access-fråga:

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

Generellt sett är anslutningssträngen du lägger i OpenDatabase Den fjärde parametern är den du skulle prefixa "tabellen" med. Därför skulle den allmänna syntaxen vara:

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

Du kan använda OpenDatabase metod och iterera över TableDefs för att hitta de giltiga namnen på tabellen. Du kan sedan använda det för att fylla i den andra delen av namnet.

Varför öppna istället för länk?

En fördel med att öppna i motsats till att länka är att du kan ändra anslutningssträngen under körning. Du behöver inte heller ta itu med den nödvändiga rensningen som att ta bort de länkade objekten som inte längre behövs. Det är rent övergående vilket skulle vara perfekt för att flytta data från en källa till en annan källa utan att skriva någon VBA-kod.

Här är ett möjligt scenario. Anta att vi vill skapa textfiler som är en utdata från en vy på vår SQL Server-databas. Du såg från tidigare artiklar att vi kunde skriva VBA-kod för att loopa över DAO-postuppsättningarna och skriva innehållet en efter en. Men som ett alternativ kan vi istället skapa en Access-fråga med denna 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];

Eftersom både destinationen och källan inte är Access källa, är detta vad vi kallar "heterogen fråga". Observera att även om vwProducts var en länkad tabell, skulle det fortfarande vara en "heterogen" fråga. Det beror på att vi fortfarande blandar olika datakällor i en enda fråga.

Ännu viktigare, genom att använda en heterogen fråga undviker vi behovet av att skapa tillfälliga objekt i vår Access-applikation. Att skapa ett tillfälligt objekt kan få Access-applikationen att svälla upp. Detta är fallet även vid import eller genom att länka eller genom att använda postuppsättningar i VBA. En uppsvälld fil kan i sin tur kräva komprimering och reparation. Men när du använder en heterogen fråga för att direkt överföra data från en datakälla till en annan, undviker du all den uppblåsthet. Följaktligen gör den den idealisk för scenarier där din Access-applikation behöver generera flera filer utan underhåll på själva applikationen.

Konstruera ad-hoc-anslutningssträngen

Vid det här laget kan du se varför det är värdefullt att förstå parametrarna som används i anslutningssträngen. Det är särskilt viktigt att kontrollera destinationen (t.ex. sökväg för textfiler eller intervallet för Excel-ark). Med dessa icke-relationella datakällor kanske det inte är intuitivt vad som utgör en "databas" och "tabeller" i en sådan datakälla. Du kan använda de tre senaste artiklarna som referens för hjälp med att konstruera anslutningssträngen och schemainformationen för att säkerställa att layouten blir rätt. Som sagt, det finns också en genväg som du kan använda för att hjälpa dig hitta anslutningssträngen.

Du kan använda fliken Extern och antingen "Importera text" eller Importera Excel" och välja länkalternativet. Det är vanligtvis det tredje alternativet i guiden som visas.

Efter att du har gått igenom guiden och sparat den nya länkade tabellen, kan du sedan inspektera anslutningssträngen via VBAs omedelbara fönster med denna kod:

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

Detta kan ge dig tips om hur du konstruerar anslutningssträngen och du kan sedan anpassa. För det mesta kommer du att hitta dig själv med att anpassa sökvägen eller tabellnamnet så att det vanligtvis fungerar tillräckligt som en teknik under din utveckling. Du kan sedan skapa en heterogen fråga i enlighet med detta och ta bort den länkade tabellen.

Slutsatser

I serien lärde du dig skillnaden mellan att länka och öppna. Du såg sedan hur Excel- och textfiler kan användas som om de vore en DAO.Database objekt med "tabeller". Med den andra artikeln lärde du dig om anslutningsparametrar för en Excel-arbetsbok. I den tredje artikeln såg du behovet av att ha schemainformation för att beskriva en textfil. Den fjärde artikeln beskrev hur man använder schema.ini . I den femte artikeln såg du hur MSysIMEXSpecs och MSysIMEXColumns kan användas som ett alternativ till schema.ini metod.

Slutligen lägger vi ihop allt i att konstruera en heterogen fråga som ett exempel på en lågkodslösning. Vi behöver inte skriva stora mängder VBA-kod bara för att skicka data från en källa till en annan källa. Jag tror att du håller med om att det är mycket lättare att ändra en Access-fråga genom att justera sökvägen eller tabellnamnet än att skriva stora och komplexa VBA-rutiner för att läsa och skriva data. Ännu viktigare genom att använda en heterogen fråga, blir det mycket lättare att hantera förändringarna i strukturen på båda sidor. Har du lagt till en ny kolumn? Inga problem, lägg bara till den nya kolumnen i frågan så är vi klara.

Men som du ser kräver detta en god förståelse för konstruktionen av anslutningssträngen. Av den anledningen var det nödvändigt att studera kopplingssträngens krångligheter på djupet som vi gjorde från 2:a till 5:e artiklarna. Även om vi kan använda den länkade tabellguiden för att ge oss tips om anslutningssträngarna. Men det är bara tips. Därför är det bra att veta hur man exakt styr utmatningen. Jag hoppas att du håller med om att en ansträngning för att förstå hur anslutningssträngar fungerar kommer att betala sig själv i sparat arbete.


  1. SQL AVG() för nybörjare

  2. Bevilja privilegier på framtida bord i PostgreSQL?

  3. Fallstudie för SQL Server Databas Server Hardware Upgrade

  4. Anrop till en medlemsfunktion execute() på boolean in