Hvordan taler Access med ODBC-datakilder? Del 5

Filtrering af postsættet

I del 5 af vores serie vil vi lære, hvordan Microsoft Access håndterer implementerede filtre og integrerer dem i ODBC-forespørgsler. I den foregående artikel så vi, hvordan Access vil formulere SELECT sætninger i ODBC SQL-kommandoer. Vi så også i den forrige artikel, hvordan Access vil forsøge at opdatere en række ved at anvende en WHERE klausul baseret på nøglen og, hvis det er relevant, rækkeversion. Vi skal dog lære, hvordan Access vil håndtere de filtre, der leveres til Access-forespørgslerne, og oversætte dem i ODBC-laget. Der er forskellige tilgange, Access kan bruge afhængigt af, hvordan Access-forespørgslerne er formuleret, og du vil lære, hvordan du forudsiger, hvordan Access vil oversætte en Access-forespørgsel til en ODBC-forespørgsel for forskellige filterprædikater.

Uanset hvordan du rent faktisk anvender filter - det være sig interaktivt via formular- eller dataarks båndkommandoer eller højremenuklik, eller programmatisk ved at bruge VBA eller køre gemte forespørgsler - vil Access udstede en tilsvarende ODBC SQL-forespørgsel for at udføre filtreringen. Generelt vil Access forsøge at fjerne så meget filtrering som muligt. Den vil dog ikke fortælle dig, hvis den ikke kan gøre det. I stedet, hvis Access ikke kan udtrykke filteret ved hjælp af ODBC SQL-syntaks, vil det i stedet forsøge at udføre filtrering selv ved at downloade hele indholdet af tabellen og evaluere betingelsen lokalt. Det kan forklare, hvorfor du nogle gange kan støde på en forespørgsel, der kører hurtigt, men med en lille ændring, bremser ned til en gennemgang. Dette afsnit vil forhåbentlig hjælpe dig med at forstå, hvornår dette kan ske, og hvordan du håndterer det, så du kan hjælpe med at få adgang til fjernadgang så meget som muligt til datakilderne for at anvende filteret.

Til denne artikel vil vi bruge gemte forespørgsler, men de oplysninger, der diskuteres her, bør stadig gælde for andre metoder til at anvende filtre.

Statiske filtre

Vi starter let og laver en gemt forespørgsel med et hårdkodet filter.

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName="Boston";

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" = 'Boston' ) 

Simple parameteriserede filtre

Lad os ændre SQL til at bruge en parameter i stedet:

PARAMETERS SelectedCityName Text ( 255 );
SELECT 
  c.CityID
 ,c.CityName
 ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName=[SelectedCityName];

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" =  ? ) 

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName=[Forms]![frmSomeForm]![txtSomeText];

Det virker også for VBA-funktionen. Vi kan tilføje en ny VBA-funktion:

Public Function GetSelectedCity() As String
    GetSelectedCity = "Boston"
End Function

WHERE c.CityName=GetSelectedCity();

Der er dog et mere almindeligt scenarie, som Access-udviklere typisk opsætter, og det er at skabe dynamisk SQL med VBA-kode, normalt ved at sammenkæde en streng og derefter udføre den sammenkædede streng. Lad os bruge følgende VBA-kode:

Public Sub GetSelectedCities()
    Dim db As DAO.Database
    Dim rs As DAO.Recordset
    Dim fld As DAO.Field
    
    Dim SelectedCity As String
    Dim SQLStatement As String
    
    SelectedCity = InputBox("Enter a city name")
    SQLStatement = _
        "SELECT c.CityID, c.CityName, c.StateProvinceID " & _
        "FROM Cities AS c " & _
        "WHERE c.CityName = '" & SelectedCity & "';"
    
    Set db = CurrentDb
    Set rs = db.OpenRecordset(SQLStatement)
    Do Until rs.EOF
        For Each fld In rs.Fields
            Debug.Print fld.Value;
        Next
        Debug.Print
        rs.MoveNext
    Loop
End Sub

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" = 'Boston' ) 

Af den grund kan parametriserede forespørgsler fra Access mod ODBC-kilder være at foretrække frem for dynamisk SQL. Fordi Access vil behandle referencekontrolelementerne på en formular eller VBA-funktioner, der ikke kræver kolonnereferencer, som parametre, behøver du ikke eksplicitte parametre i dine recordsourcer eller rækkekilder. Men hvis du bruger VBA til at udføre SQL, er det normalt bedre at bruge ADO, som også har meget bedre understøttelse af parametrering. I tilfælde af at bygge en dynamisk recordsource eller rowsource, kan brug af en skjult kontrol på formularen/rapporten være en nem måde at parametrere forespørgslen på. Men hvis forespørgslen er markant anderledes, fremtvinger opbygning af den dynamiske SQL i VBA og tildeling af den til egenskaben recordsource/rowsource effektivt en fuld rekompilering og undgår derfor at bruge dårlige eksekveringsplaner, der ikke vil fungere godt for det aktuelle sæt af input. Du kan finde anbefalinger i artiklen, der diskuterer SQL Servers WITH RECOMPILE nyttigt at beslutte, om der skal gennemtvinges en rekompilering i forhold til at bruge en parameteriseret forespørgsel.

Brug af funktioner i SQL-filtrering

I forrige afsnit så vi, at en SQL-sætning indeholdende en VBA-funktion blev parameteriseret, så Access kunne udføre VBA-funktionen og bruge outputtet som input til den parametrerede forespørgsel. Det er dog ikke alle indbyggede funktioner, der opfører sig på denne måde. Lad os bruge UCase() som et eksempel for at filtrere forespørgslen. Desuden vil vi anvende funktionen på en kolonne.

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE UCase([c].[CityName])="BOSTON";

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ({fn ucase("CityName" )}= 'BOSTON' )

Hvis vi så opretter en brugerdefineret VBA-funktion, der emulerer UCase() funktion:

Public Function MyUCase(InputValue As Variant) As String
    MyUCase = UCase(InputValue)
End Function

WHERE MyUCase([c].[CityName])="BOSTON";

SQLExecDirect: 
SELECT 
   "CityName"
  ,"c"."CityID" 
FROM "Application"."Cities" "c" 

Selvom vi brugte UCase() i dette eksempel kan vi tydeligt se, at det generelt er bedre at fjerne så meget arbejde som muligt til datakilden. Men hvad nu hvis vi har en kompleks VBA-funktion, der ikke kan omskrives til datakildens oprindelige SQL-dialekt? Selvom jeg tror, ​​at dette scenarie er ret sjældent, er det værd at overveje. Lad os antage, at vi kan tilføje et filter for at indsnævre antallet af returnerede byer.

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName LIKE "Bos*"
  AND MyUCase([c].[CityName])="BOSTON";

SQLExecDirect: 
SELECT 
   "CityName"
  ,"c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" LIKE 'Bos%' ) 

Dette fortæller os, at hvis vi står over for det uønskede scenarie, hvor vi ikke nemt kan omstrukturere en kompleks VBA-funktion fra en forespørgsel, kan vi stadig afbøde de dårlige effekter ved at tilføje filtre, der kan fjernes for at reducere det indledende sæt af poster, som Access kan arbejde med.

En bemærkning om sargerbarhed

I de foregående eksempler anvendte vi en skalarfunktion på en kolonne. Det har potentialet til at gøre forespørgslen som "ikke-sargerbar", hvilket betyder, at databasemotoren ikke er i stand til at optimere forespørgslen ved at bruge indeks til at søge og finde matches. "Sarg"-delen af ​​ordet "sargability" refererer til "Søgeargument". Antag, at vi har indekset defineret ved datakilden i tabellen:

CREATE INDEX IX_Cities_CityName
ON Application.Cities (CityName);

CREATE INDEX IX_Cities_Boston_Uppercase
ON Application.Cities (CityName)
WHERE UCASE(CityName) = 'BOSTON';

Uanset hvilken databasemotor du rent faktisk arbejder med, er det altid at foretrække at designe og bruge sargerbare forespørgsler, hvor det er muligt for at undgå ydeevneproblemer. Afgørende forespørgsler bør have dækkende indekser for at give den bedste ydeevne. Jeg opfordrer dig til at studere mere om sargerbarheden og dækkende indekser for at hjælpe dig med at undgå at designe forespørgsler, der faktisk ikke er sargerbare.

Konklusioner

Vi gennemgik, hvordan Access håndterer anvendelse af filtre fra Access SQL i ODBC-forespørgslerne. Vi undersøgte også forskellige tilfælde, hvor Access vil konvertere forskellige typer referencer til en parameter, hvilket giver Access mulighed for at udføre evalueringen uden for ODBC-laget og overføre dem som input til den forberedte ODBC-sætning. Vi har også set på, hvad der sker, når det ikke kan parametreres, typisk på grund af at indeholde kolonnereferencer som input. Det kan have konsekvenser for ydeevnen under en migrering til SQL-server.

For visse funktioner kan Access muligvis konvertere udtrykket til at bruge ODBC-skalarfunktioner i stedet, hvilket giver Access mulighed for at fjerne udtrykket til ODBC-datakilden. En konsekvens af dette er, at hvis implementeringen af ​​den skalære funktion er anderledes, kan det få forespørgslen til at opføre sig anderledes eller kan udføre hurtigere/langsommere. Vi så, hvordan en VBA-funktion, selv en simpel en, der omslutter en ellers fjernbar skalarfunktion, kan besejre bestræbelserne på at fjerne udtrykket. Vi lærer også, at hvis vi har en situation, hvor vi ikke kan refaktorisere en kompleks VBA-funktion fra en Access-forespørgsel/recordsource/rowsource, kan vi i det mindste mindske den dyre download ved at tilføje yderligere filtre på forespørgslen, der kan fjernes for at reducere mængden af returnerede data.

I den næste artikel vil vi se på, hvordan joins håndteres af Access.

Leder du efter hjælp til Microsoft Access? Ring til vores eksperter i dag på 773-809-5456 eller e-mail os på [email protected].