In che modo Access comunica con le origini dati ODBC? Parte 5

Filtraggio del recordset

Nella parte 5 della nostra serie, impareremo come Microsoft Access gestisce i filtri implementati e li integra nelle query ODBC. Nell'articolo precedente, abbiamo visto come Access formulerà il SELECT istruzioni nei comandi SQL ODBC. Abbiamo anche visto nell'articolo precedente come Access tenterà di aggiornare una riga applicando un WHERE clausola basata sulla chiave e, se applicabile, rowversion. Tuttavia, dobbiamo imparare come Access gestirà i filtri forniti alle query di Access e li tradurrà nel livello ODBC. Esistono diversi approcci che Access può utilizzare a seconda di come vengono formulate le query di Access e imparerai come prevedere in che modo Access tradurrà una query di Access in una query ODBC per diversi predicati di filtro forniti.

Indipendentemente da come si applica effettivamente il filtro, sia in modo interattivo tramite i comandi del modulo o del foglio dati o i clic del menu a destra, sia a livello di codice utilizzando VBA o eseguendo query salvate, Access emetterà una query SQL ODBC corrispondente per eseguire il filtraggio. In generale, Access tenterà di filtrare il più possibile in remoto. Tuttavia, non ti dirà se non può farlo. Se invece Access non è in grado di esprimere il filtro utilizzando la sintassi SQL ODBC, tenterà invece di eseguire il filtraggio scaricando l'intero contenuto della tabella e valutando la condizione in locale. Questo può spiegare perché a volte potresti riscontrare una query che viene eseguita rapidamente ma con una piccola modifica, rallenta fino a una scansione. Si spera che questa sezione ti aiuti a capire quando ciò può accadere e come gestirlo in modo che tu possa aiutare ad accedere il più possibile in remoto alle origini dati per l'applicazione del filtro.

Per questo articolo utilizzeremo le query salvate, ma le informazioni discusse qui dovrebbero essere comunque valide per altri metodi di applicazione dei filtri.

Filtri statici

Inizieremo facilmente e creeremo una query salvata con un filtro hardcoded.

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' ) 

Filtri parametrizzati semplici

Cambiamo l'SQL per usare invece un parametro:

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];

Funziona anche per la funzione VBA. Possiamo aggiungere una nuova funzione VBA:

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

WHERE c.CityName=GetSelectedCity();

Tuttavia, esiste un altro scenario comune che gli sviluppatori di Access in genere impostano e che consiste nella creazione di SQL dinamico con codice VBA, in genere concatenando una stringa e quindi eseguendo la stringa concatenata. Usiamo il seguente codice VBA:

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' ) 

Per questo motivo, le query parametrizzate da Access su origini ODBC possono essere preferibili rispetto all'SQL dinamico. Poiché Access tratterà i controlli dei riferimenti in una maschera o in funzioni VBA che non richiedono riferimenti alle colonne come parametri, non sono necessari parametri espliciti nelle origini record o nelle origini riga. Tuttavia, se stai usando VBA per eseguire SQL, di solito è meglio usare ADO che ha anche un supporto molto migliore per la parametrizzazione. Nel caso della creazione di un recordsource dinamico o di un rowsource, l'uso di un controllo nascosto nel form/report può essere un modo semplice per parametrizzare la query. Tuttavia, se la query è notevolmente diversa, la creazione dell'SQL dinamico in VBA e l'assegnazione alla proprietà recordsource/rowsource forza efficacemente una ricompilazione completa e quindi evita di utilizzare piani di esecuzione non validi che non funzioneranno bene per l'attuale set di input. È possibile trovare consigli nell'articolo relativo a WITH RECOMPILE di SQL Server utile per decidere se forzare una ricompilazione rispetto all'utilizzo di una query con parametri.

Utilizzo delle funzioni nel filtraggio SQL

Nella sezione precedente, abbiamo visto che un'istruzione SQL contenente una funzione VBA è stata parametrizzata in modo che Access potesse eseguire la funzione VBA e utilizzare l'output come input per la query parametrizzata. Tuttavia, non tutte le funzioni integrate si comportano in questo modo. Usiamo UCase() come esempio per filtrare la query. Inoltre, applicheremo la funzione su una colonna.

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' )

Se poi creiamo una funzione VBA personalizzata che emula UCase() funzione:

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" 

Anche se abbiamo usato UCase() in questo esempio, possiamo vedere chiaramente che generalmente è meglio trasferire in remoto quanto più lavoro possibile all'origine dati. Ma cosa succede se abbiamo una funzione VBA complessa che non può essere riscritta nel dialetto SQL nativo dell'origine dati? Anche se penso che questo scenario sia piuttosto raro, vale la pena considerare. Supponiamo di poter aggiungere un filtro per restringere l'insieme di città restituite.

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%' ) 

Questo ci dice che se affrontiamo lo scenario indesiderabile in cui non possiamo facilmente refactoring di una complessa funzione VBA da una query, possiamo comunque mitigare gli effetti negativi aggiungendo filtri che possono essere remoti per ridurre il set iniziale di record con cui Access può lavorare.

Una nota sulla sargability

Negli esempi precedenti, abbiamo applicato una funzione scalare su una colonna. Ciò ha il potenziale per rendere la query "non sargable", il che significa che il motore di database non è in grado di ottimizzare la query utilizzando l'indice per cercare e trovare corrispondenze. La parte "sarg" della parola "sargability" si riferisce a "Search ARGument". Supponiamo di avere l'indice definito nell'origine dati sulla tabella:

CREATE INDEX IX_Cities_CityName
ON Application.Cities (CityName);

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

Indipendentemente dal motore di database con cui stai effettivamente lavorando, è sempre preferibile progettare e utilizzare query sargable ove possibile per evitare problemi di prestazioni. Le query cruciali dovrebbero coprire gli indici per fornire le migliori prestazioni. Ti incoraggio a studiare di più sulla sargability e sugli indici di copertura per aiutarti a evitare di progettare query che in realtà non sono sargable.

Conclusioni

Abbiamo esaminato il modo in cui Access gestisce l'applicazione dei filtri da Access SQL alle query ODBC. Abbiamo anche esplorato diversi casi in cui Access convertirà diversi tipi di riferimenti in un parametro, consentendo ad Access di eseguire la valutazione al di fuori del livello ODBC e passandoli come input nell'istruzione ODBC preparata. Abbiamo anche esaminato cosa succede quando non può essere parametrizzato, in genere a causa del contenuto di riferimenti di colonna come input. Ciò può avere conseguenze sulle prestazioni durante una migrazione al server SQL.

Per determinate funzioni, Access potrebbe essere in grado di convertire l'espressione per utilizzare invece le funzioni scalari ODBC, che consentono ad Access di eseguire in remoto l'espressione nell'origine dati ODBC. Una ramificazione di ciò è che se l'implementazione della funzione scalare è diversa, la query potrebbe comportarsi in modo diverso o potrebbe funzionare più velocemente/lentamente. Abbiamo visto come una funzione VBA, anche una semplice che avvolge una funzione scalare altrimenti remotabile, può vanificare gli sforzi per remotare l'espressione. Impariamo anche che se abbiamo una situazione in cui non possiamo eseguire il refactoring di una complessa funzione VBA da una query/recordsource/rowsource di Access, possiamo almeno mitigare il costoso download aggiungendo filtri aggiuntivi sulla query che possono essere remoti per ridurre l'importo dei dati restituiti.

Nel prossimo articolo vedremo come vengono gestiti i join da Access.

Cerchi aiuto con Microsoft Access? Chiama i nostri esperti oggi al 773-809-5456 o inviaci un'e-mail a [email protected].