Wie kommuniziert Access mit ODBC-Datenquellen? Teil 5

Filtern des Datensatzes

In Teil 5 unserer Serie erfahren Sie, wie Microsoft Access mit implementierten Filtern umgeht und diese in ODBC-Abfragen integriert. Im vorherigen Artikel haben wir gesehen, wie Access den SELECT formuliert Anweisungen in den ODBC-SQL-Befehlen. Wir haben im vorherigen Artikel auch gesehen, wie Access versucht, eine Zeile durch Anwenden eines WHERE zu aktualisieren -Klausel basierend auf dem Schlüssel und gegebenenfalls der Zeilenversion. Wir müssen jedoch lernen, wie Access mit den Filtern umgeht, die den Access-Abfragen bereitgestellt werden, und sie in der ODBC-Schicht übersetzt. Es gibt verschiedene Ansätze, die Access verwenden kann, je nachdem, wie die Access-Abfragen formuliert sind, und Sie werden lernen, wie Sie vorhersagen können, wie Access eine Access-Abfrage in eine ODBC-Abfrage für verschiedene gegebene Filterprädikate übersetzt.

Unabhängig davon, wie Sie den Filter tatsächlich anwenden – sei es interaktiv über Menübandbefehle des Formulars oder des Datenblatts oder Rechtsklicks im Menü oder programmgesteuert mit VBA oder Ausführen gespeicherter Abfragen – Access gibt eine entsprechende ODBC-SQL-Abfrage aus, um die Filterung durchzuführen. Im Allgemeinen versucht Access, so weit wie möglich zu filtern. Es wird Ihnen jedoch nicht mitgeteilt, ob dies nicht möglich ist. Wenn Access den Filter stattdessen nicht mithilfe der ODBC-SQL-Syntax ausdrücken kann, versucht es stattdessen, die Filterung selbst durchzuführen, indem es den gesamten Inhalt der Tabelle herunterlädt und die Bedingung lokal auswertet. Das kann erklären, warum Sie manchmal auf eine Abfrage stoßen, die schnell ausgeführt wird, aber mit einer kleinen Änderung zu einem Crawl verlangsamt wird. Dieser Abschnitt hilft Ihnen hoffentlich zu verstehen, wann dies passieren kann und wie Sie damit umgehen, damit Sie so weit wie möglich auf die Datenquellen für die Anwendung des Filters zugreifen können.

Für diesen Artikel verwenden wir gespeicherte Abfragen, aber die hier besprochenen Informationen sollten auch für andere Methoden zum Anwenden von Filtern gelten.

Statische Filter

Wir fangen einfach an und erstellen eine gespeicherte Abfrage mit einem hartcodierten 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' ) 

Einfache parametrisierte Filter

Lassen Sie uns die SQL ändern, um stattdessen einen Parameter zu verwenden:

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

Das funktioniert auch für die VBA-Funktion. Wir können eine neue VBA-Funktion hinzufügen:

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

WHERE c.CityName=GetSelectedCity();

Es gibt jedoch ein weiteres häufiges Szenario, das Access-Entwickler normalerweise einrichten, und das ist das Erstellen von dynamischem SQL mit VBA-Code, normalerweise durch Verketten einer Zeichenfolge und anschließendes Ausführen der verketteten Zeichenfolge. Lassen Sie uns den folgenden VBA-Code verwenden:

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

Aus diesem Grund sind parametrisierte Abfragen von Access für ODBC-Quellen möglicherweise gegenüber dynamischem SQL vorzuziehen. Da Access die Referenzsteuerelemente in einem Formular oder VBA-Funktionen behandelt, die keine Spaltenreferenzen als Parameter erfordern, benötigen Sie keine expliziten Parameter in Ihren Datensatzquellen oder Zeilenquellen. Wenn Sie jedoch VBA zum Ausführen von SQL verwenden, ist es normalerweise besser, ADO zu verwenden, das auch eine viel bessere Unterstützung für die Parametrisierung bietet. Beim Erstellen einer dynamischen Datensatzquelle oder Zeilenquelle kann die Verwendung eines verborgenen Steuerelements im Formular/Bericht eine einfache Möglichkeit sein, die Abfrage zu parametrisieren. Wenn sich die Abfrage jedoch deutlich unterscheidet, erzwingt das Erstellen des dynamischen SQL in VBA und das Zuweisen zur Eigenschaft recordsource/rowsource effektiv eine vollständige Neukompilierung und vermeidet daher die Verwendung schlechter Ausführungspläne, die für den aktuellen Satz von Eingaben keine gute Leistung erbringen. Möglicherweise finden Sie Empfehlungen in dem Artikel über WITH RECOMPILE von SQL Server hilfreich bei der Entscheidung, ob eine Neukompilierung oder eine parametrisierte Abfrage erzwungen werden soll.

Funktionen in der SQL-Filterung verwenden

Im vorherigen Abschnitt haben wir gesehen, dass eine SQL-Anweisung, die eine VBA-Funktion enthält, parametrisiert wurde, sodass Access die VBA-Funktion ausführen und die Ausgabe als Eingabe für die parametrisierte Abfrage verwenden konnte. Allerdings verhalten sich nicht alle integrierten Funktionen auf diese Weise. Lassen Sie uns UCase() verwenden als Beispiel, um die Abfrage zu filtern. Außerdem wenden wir die Funktion auf eine Spalte an.

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

Wenn wir dann eine benutzerdefinierte VBA-Funktion erstellen, die UCase() emuliert 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" 

Obwohl wir UCase() verwendet haben In diesem Beispiel können wir deutlich sehen, dass es im Allgemeinen besser ist, so viel Arbeit wie möglich an die Datenquelle zu verlagern. Was aber, wenn wir eine komplexe VBA-Funktion haben, die nicht in den nativen SQL-Dialekt der Datenquelle umgeschrieben werden kann? Obwohl ich denke, dass dieses Szenario ziemlich selten ist, ist es eine Überlegung wert. Angenommen, wir können einen Filter hinzufügen, um die zurückgegebenen Städte einzugrenzen.

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

Dies sagt uns, wenn wir mit dem unerwünschten Szenario konfrontiert sind, in dem wir eine komplexe VBA-Funktion nicht einfach aus einer Abfrage umgestalten können, können wir die negativen Auswirkungen dennoch abmildern, indem wir Filter hinzufügen, die entfernt werden können, um den anfänglichen Satz von Datensätzen zu reduzieren, mit denen Access arbeiten kann.

Ein Hinweis zur Sargability

In den vorangegangenen Beispielen haben wir eine Skalarfunktion auf eine Spalte angewendet. Dies kann dazu führen, dass die Abfrage als „nicht sargable“ dargestellt wird, was bedeutet, dass die Datenbank-Engine die Abfrage nicht optimieren kann, indem sie den Index verwendet, um Übereinstimmungen zu suchen und zu finden. Der „sarg“-Teil des Wortes „sargability“ bezieht sich auf „Search ARGument“. Angenommen, wir haben den Index in der Datenquelle für die Tabelle definiert:

CREATE INDEX IX_Cities_CityName
ON Application.Cities (CityName);

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

Unabhängig davon, mit welcher Datenbank-Engine Sie tatsächlich arbeiten, ist es immer vorzuziehen, Sargable-Abfragen zu entwerfen und zu verwenden, wo immer dies möglich ist, um Leistungsprobleme zu vermeiden. Entscheidende Abfragen sollten abdeckende Indizes haben, um die beste Leistung zu erzielen. Ich ermutige Sie, mehr über die Sargability und das Abdecken von Indizes zu lernen, um das Entwerfen von Abfragen zu vermeiden, die tatsächlich nicht sargable sind.

Schlussfolgerungen

Wir haben überprüft, wie Access das Anwenden von Filtern von Access SQL auf die ODBC-Abfragen handhabt. Wir haben auch verschiedene Fälle untersucht, in denen Access verschiedene Arten von Verweisen in einen Parameter konvertiert, sodass Access die Auswertung außerhalb der ODBC-Schicht durchführen und sie als Eingaben an die vorbereitete ODBC-Anweisung übergeben kann. Wir haben uns auch angesehen, was passiert, wenn es nicht parametrisiert werden kann, typischerweise weil Spaltenreferenzen als Eingaben enthalten sind. Das kann Auswirkungen auf die Performance bei einer Migration auf SQL Server haben.

Bei bestimmten Funktionen kann Access möglicherweise den Ausdruck konvertieren, um stattdessen ODBC-Skalarfunktionen zu verwenden, wodurch Access den Ausdruck remote an die ODBC-Datenquelle übertragen kann. Eine Folge davon ist, dass eine andere Implementierung der Skalarfunktion dazu führen kann, dass sich die Abfrage anders verhält oder schneller/langsamer ausgeführt wird. Wir haben gesehen, wie eine VBA-Funktion, sogar eine einfache, die eine ansonsten remote-fähige Skalarfunktion umschließt, die Bemühungen um Remote-Ausdruck zunichte machen kann. Wir lernen auch, dass wir, wenn wir eine Situation haben, in der wir eine komplexe VBA-Funktion nicht aus einer Access-Abfrage/Recordsource/Rowsource umgestalten können, den teuren Download zumindest abmildern können, indem wir der Abfrage zusätzliche Filter hinzufügen, die entfernt werden können, um die Menge zu reduzieren der zurückgegebenen Daten.

Im nächsten Artikel werden wir uns ansehen, wie Joins von Access gehandhabt werden.

Suchen Sie Hilfe zu Microsoft Access? Rufen Sie noch heute unsere Experten unter 773-809-5456 an oder senden Sie uns eine E-Mail an [email protected].