sql >> Database >  >> RDS >> Access

Verbindingsreeksparameters voor Excel-gegevensbronnen

Verbindingsreeksparameters voor Excel-gegevensbronnen

In het vorige artikel heb ik besproken hoe we Excel- en tekstbestanden kunnen behandelen alsof ze een database zijn met behulp van DAO, en hoe we ze kunnen openen zonder te linken. Omdat ze geen ODBC-stuurprogramma's gebruiken, zal hun verbindingsreeks heel anders worden opgemaakt dan u misschien gewend bent te zien voor een ODBC-verbindingsreeks. Er is een gebrek aan documentatie over de parameters van de Excel-verbindingsreeks. Dit is een beste poging om enkele hiaten te dichten en de gevolgen van parameters te bespreken.

Excel-verbindingsreeksparameters

Ook al hebben we 3 verschillende "types" gegevensbronnen:

  1. Excel 8.0 :97-2003 xls-bestanden
  2. Excel 12.0 :xlsb-bestanden
  3. Excel 12.0 Xml :xlsx-bestanden

Ze gebruiken allemaal dezelfde parameters.

Hier is de lijst met parameters:

HDR parameter:kopregel

YES :De eerste rij is de kop en zouden de kolomnamen moeten worden voor de “tabel”/”recordset”
NO :De eerste rij wordt niet anders behandeld en is slechts een gegevens. Alle kolomnamen krijgen de naam "FN" waarbij "N" een getal is dat begint met 1

IMEX parameter:Import/Export Gedrag

Dit bepaalt hoe de kolomgegevenstypen moeten worden gedefinieerd, op basis van de inhoud:
1 :Als de kolom verschillende gegevenstypen bevat, behandel deze dan als een tekenreeks. Zoek anders de kolom naar het beste gegevenstype.
2 :stem de kolom altijd af op een bepaald gegevenstype op basis van het voorbeeld. Dat kan een leesfout veroorzaken wanneer we een rij lezen die gegevens bevat die niet overeenkomen met het verwachte gegevenstype.

ACCDB parameter:geeft aan dat Access ACCDB-bestandsindeling gebruikt?

Standaard is dit altijd ACCDB=YES ingesteld in een accdb-bestandsformaat. Echter, weglaten of instellen op NEE lijkt niets te doen. Het is een beetje een mysterie. Als iemand kan delen welk effect deze parameter heeft, plaats dan een reactie en ik zal de blog bijwerken.

DATABASE:pad naar de Excel-werkmap

De parameter moet een volledig gekwalificeerd pad bevatten, inclusief de naam van de werkmap.

Minimaal werkende verbindingsreeks

Houd er rekening mee dat de DATABASE de enige verplichte parameter is naast het sleutelwoord datatype source. Daarom kan een minimaal werkende verbindingsreeks zijn:

Excel 8.0;DATABASE=C:\Links\Products.xls

Blad of bereik specificeren in verbindingsreeks

In het vorige voorbeeld zag je dat een blad een "DAO.TableDef . voorstelde “. Werkbladen zijn echter niet het enige dat een "Tabledef . kan zijn “. Als het Excel-spreadsheet een benoemd bereik bevat, wordt het genoemde bereik gerapporteerd als een "Tabledef " ook. Bovendien kunnen we een willekeurig blok in het blad "opvragen" met behulp van het celadres. Bijvoorbeeld:

Dim db As DAO.Database
Dim rs As DAO.Recordset

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

Debug.Print rs.Name, rs.Fields.Count

Het is belangrijk op te merken dat de celadressen het gebruikte bereik van het blad niet kunnen overschrijden. Bijvoorbeeld de Products.xlsx heeft alleen inhoud in A1:B3, dat betekent dat als je een recordset opent met Blad1$A1:D5, je nog steeds maar 2 krijgt voor het aantal velden en 3 voor het aantal records. De extra lege kolommen/rijen worden gewoon genegeerd. Aan de andere kant, als je een cel ergens buiten de A1:B3 , de UsedRange . van het blad zal nu even groter zijn en zoekopdrachten zouden dan lege kolommen en rijen bevatten.

Daarom zijn dit geldige namen om te gebruiken in een query op een Excel "database":

  1. Sheet1$ – Gehele gebruikte bereik van een werkblad.
  2. Sheet1$A1:B4 – Slechts 2 kolommen en 3 rijen (koptekst niet meegerekend), op voorwaarde dat de inhoud gevuld is. Anders kunnen kolommen of rijen minder zijn dan gevraagd.
  3. ProductsRange – het benoemde bereik met die naam.

Ik vind het veel leuker om benoemde bereiken te gebruiken waar dat praktisch is, omdat dit ervoor zorgt dat je de adressen in je code niet hard codeert, vooral als het bereik wordt verplaatst omdat de gebruiker nieuwe kolommen of rijen invoegt, maar de inhoud van het benoemde bereik niet verandert . Het is echter niet altijd praktisch, vooral als u spreadsheets van een derde partij ontvangt en daarom geen controle hebt over de inhoud of indelingen. In dit geval kan het schrijven van een SQL-query ook werken.

Opvragen van Excel-gegevensbron

Stel dat we het formaat niet kunnen controleren en we niet willen vertrouwen op een absoluut adres, ook al zijn we er zeker van dat bepaalde kolommen en rijen inderdaad aanwezig zullen zijn. In die situatie kun je het beste een query uitvoeren. Hier is een voorbeeld dat slechts één rij selecteert:

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

  Dim rs As DAO.Recordset
  Set rs = db.OpenRecordset("SELECT d.[Count] FROM [Sheet1$] AS d WHERE d.[Products] = 'Bananas';")
  Debug.Print rs.Fields(0).Value

Hopelijk kun je zien dat dit veel gemakkelijker is dan elke rij te herhalen om te zien welke "bananen" heeft en dan de kolom naar rechts te lezen om de telling te krijgen. In dit geval is het opvragen beter dan het automatiseren van Excel.

Conclusie

Je hebt gezien dat DAO het voor ons heel gemakkelijk maakt om met Excel-gegevensbronnen te werken en te doen alsof het een relationele gegevensbron is en onze favoriete querytaal en bekende DAO-objecten te gebruiken in plaats van een heleboel VBA-code te schrijven die Excel automatiseert om de gegevens die we willen. De parameters van de verbindingsreeks zijn redelijk eenvoudig en zolang je het pad hebt, kun je een Excel-spreadsheet koppelen of openen.

In het volgende artikel zullen we kijken naar de verbindingsparameters voor tekstbestanden.


  1. PostgreSQL:prestatie pg_dump, pg_restore verbeteren

  2. Barman automatiseren met Puppet:it2ndq/barman (deel één)

  3. Hoe rijen in SQL Server-tabel in te voegen door de GUI van tabelrijen te bewerken - SQL Server / TSQL-zelfstudie, deel 101

  4. Applicatiegebruikers versus beveiliging op rijniveau