Wie kommuniziert Access mit ODBC-Datenquellen? Teil 3

Analysieren Sie die Abfrage der Schlüsselpopulation weiter

In Teil 3 unserer Serie zur ODBC-Ablaufverfolgung werden wir einen weiteren Einblick in die Verwaltung von Schlüsseln für ODBC-verknüpfte Tabellen durch Access erhalten und wie die SELECT-Abfragen sortiert und gruppiert werden. Im vorherigen Artikel haben wir gelernt, dass ein Datensatz vom Typ Dynaset tatsächlich aus zwei separaten Abfragen besteht, wobei die erste Abfrage nur die Schlüssel der mit ODBC verknüpften Tabelle abruft, die dann anschließend zum Auffüllen der Daten verwendet wird. In diesem Artikel werden wir ein wenig mehr darüber untersuchen, wie Access die Schlüssel verwaltet und wie daraus abgeleitet wird, welcher Schlüssel für eine ODBC-verknüpfte Tabelle verwendet werden soll, und welche Auswirkungen dies hat. Wir beginnen mit der Sortierung.

Hinzufügen einer Sortierung zur Abfrage

Sie haben im vorherigen Artikel gesehen, dass wir mit einem einfachen SELECT begonnen haben ohne besondere Bestellung. Sie haben auch gesehen, wie Access zuerst die CityID abgerufen hat und verwenden Sie das Ergebnis der ersten Abfrage, um dann die nachfolgenden Abfragen zu füllen, um dem Benutzer beim Öffnen eines großen Datensatzes den Anschein zu erwecken, schnell zu sein. Wenn Sie jemals eine Situation erlebt haben, in der das Hinzufügen einer Sortierung oder Gruppierung zu einer Abfrage plötzlich langsam wurde, wird dies erklären, warum.

Fügen wir der StateProvinceID eine Sortierung hinzu in einer Access-Abfrage:

SELECT Cities.*
FROM Cities
ORDER BY Cities.StateProvinceID;

SQLExecDirect: 
SELECT "Application"."Cities"."CityID" 
FROM "Application"."Cities" 
ORDER BY "Application"."Cities"."StateProvinceID"  

SQLPrepare: 
SELECT 
  "CityID",
  "CityName",
  "StateProvinceID",
  "Location",
  "LatestRecordedPopulation",
  "LastEditedBy",
  "ValidFrom",
  "ValidTo"  
FROM "Application"."Cities"  
WHERE "CityID" = ?

SQLExecute: (GOTO BOOKMARK)

SQLPrepare: 
SELECT 
  "CityID",
  "CityName",
  "StateProvinceID",
  "Location",
  "LatestRecordedPopulation",
  "LastEditedBy",
  "ValidFrom",
  "ValidTo"  
FROM "Application"."Cities"  
WHERE "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ? 
   OR "CityID" = ?

SQLExecute: (MULTI-ROW FETCH)

SQLExecute: (MULTI-ROW FETCH)

Betrachten wir, was passiert, wenn wir ein GROUP BY hinzufügen indem Sie die Städte pro Staat zählen:

SELECT 
   Cities.StateProvinceID
  ,Count(Cities.CityID) AS CountOfCityID
FROM Cities
GROUP BY Cities.StateProvinceID;

SQLExecDirect: 
SELECT 
   "StateProvinceID"
  ,COUNT("CityID" )  
FROM "Application"."Cities" 
GROUP BY "StateProvinceID"

Nur weil der Standardwert ein Recordset vom Typ Dynaset ist, ist folglich nicht garantiert, dass es sich tatsächlich um ein Recordset vom Typ Dynaset handelt. Es ist lediglich eine Anfrage , keine Nachfrage.

Festlegen des Schlüssels zum Auswählen

Möglicherweise haben Sie im vorherigen nachverfolgten SQL sowohl in diesem als auch in früheren Artikeln bemerkt, dass Access die CityID verwendet hat als Schlüssel. Diese Spalte wurde in der ersten Abfrage abgerufen und dann in nachfolgenden vorbereiteten Abfragen verwendet. Aber woher weiß Access, welche Spalte(n) einer verknüpften Tabelle es verwenden soll? Die erste Neigung wäre zu sagen, dass es nach einem Primärschlüssel sucht und diesen verwendet. Das wäre jedoch falsch. Tatsächlich verwendet die Access-Datenbank-Engine die SQLStatistics von ODBC Funktion beim Verknüpfen oder erneuten Verknüpfen der Tabelle, um zu prüfen, welche Indizes verfügbar sind. Diese Funktion gibt eine Ergebnismenge mit einer Zeile für jede Spalte zurück, die an einem Index für alle Indizes teilnimmt. Diese Ergebnismenge ist immer sortiert und sortiert gemäß Konvention immer geclusterte Indizes, gehashte Indizes und dann andere Indextypen. Innerhalb jedes Indextyps werden die Indizes alphabetisch nach ihren Namen sortiert. Das Access-Datenbankmodul wählt den ersten eindeutigen Index aus, den es findet, auch wenn es sich nicht um den tatsächlichen Primärschlüssel handelt. Um dies zu beweisen, erstellen wir eine dumme Tabelle mit einigen ungeraden Indizes:

CREATE TABLE dbo.SillyTable (
	ID int 
		CONSTRAINT PK_SillyTable PRIMARY KEY NONCLUSTERED,
	OtherStuff int
		CONSTRAINT UQ_SillyTable_OtherStuff UNIQUE CLUSTERED,
	SomeValue nvarchar(255)
);

SQLExecDirect: 
SELECT "dbo"."SillyTable"."OtherStuff" 
FROM "dbo"."SillyTable" 

SQLPrepare: SELECT 
   "ID"
  ,"OtherStuff"
  ,"SomeValue"  
FROM "dbo"."SillyTable"  
WHERE "OtherStuff" = ?

Zugriffsseitiger Index für verknüpfte SQL-Ansicht oder -Tabelle ohne Indizes

Beim Verknüpfen mit einer SQL-Ansicht oder einer SQL-Tabelle, für die keine Indizes oder Primärschlüssel definiert sind, stehen keine Indizes zur Verfügung, die von der Access-Datenbank-Engine verwendet werden können. Wenn Sie Linked Table Manager verwendet haben, um eine Tabelle oder eine SQL-Ansicht ohne Indizes zu verknüpfen, haben Sie möglicherweise einen Dialog wie diesen gesehen:

Wenn wir die ID auswählen , schließen Sie die Verknüpfung ab, öffnen Sie die verknüpfte Tabelle in der Entwurfsansicht und dann den Indexdialog, wir sollten Folgendes sehen:

Es zeigt, dass die Tabelle einen Index namens __uniqueindex hat aber es existiert nicht in der ursprünglichen Datenquelle. Was ist los? Die Antwort ist, dass Access eine Access-Seite erstellt hat Index für seine Verwendung, um zu identifizieren, was als Datensatzkennung für solche Tabellen oder Ansichten verwendet werden kann. Wenn Sie die Tabellen programmgesteuert neu verknüpfen, anstatt den Linked Table Manager zu verwenden, müssen Sie das Verhalten replizieren, um solche verknüpften Tabellen aktualisierbar zu machen. Dies kann durch Ausführen eines Access SQL-Befehls erfolgen:

CREATE UNIQUE INDEX [__uniqueindex] ON SillyTable (ID);

Es ist erwähnenswert, dass Access nur genau einen Index für eine solche verknüpfte Tabelle zulässt und nur dann, wenn es noch keine Indizes gibt. Dennoch können Sie sehen, dass die Verwendung einer SQL-Ansicht eine wünschenswerte Option für Fälle sein kann, in denen das Datenbankdesign die Verwendung von gruppierten Indizes nicht zulässt und Sie nicht mit dem Namen des Index herumspielen möchten, um die Access-Datenbank-Engine davon zu überzeugen, diesen Index zu verwenden. nicht dieser Index. Sie können den Index und die darin enthaltenen Spalten explizit steuern, wenn Sie die SQL-Ansicht verknüpfen.

Schlussfolgerungen

Aus dem vorherigen Artikel haben wir gesehen, dass ein Recordset vom Typ Dynaset normalerweise zwei Abfragen ausgibt. Die erste Abfrage befasst sich normalerweise mit dem Auffüllen der Wir haben uns genauer angesehen, wie Access mit dem Auffüllen von Schlüsseln umgeht, die für ein Recordset vom Typ Dynaset verwendet werden. Wir haben gesehen, wie Access tatsächlich jede Sortierung aus der ursprünglichen Access-Abfrage konvertiert und diese dann in der Schlüsselauffüllungsabfrage verwendet. Wir haben gesehen, dass sich die Reihenfolge der Schlüsselauffüllungsabfrage direkt darauf auswirkt, wie die Daten im Recordset sortiert und dem Benutzer präsentiert werden. Dies ermöglicht dem Benutzer Dinge wie das Springen zu einem beliebigen Datensatz basierend auf der Ordnungsposition der Liste.

Wir haben dann gesehen, dass Gruppierungen und andere SQL-Vorgänge, die eine Eins-zu-Eins-Zuordnung zwischen der zurückgegebenen Zeile und der ursprünglichen Zeile verhindern, dazu führen, dass Access die Access-Abfrage so behandelt, als wäre es ein Recordset vom Snapshot-Typ, obwohl ein Recordset vom Typ Dynaset angefordert wird.

Wir haben uns dann angesehen, wie Access den Schlüssel bestimmt, der zum Verwalten von Updates mit einer ODBC-verknüpften Tabelle verwendet werden soll. Im Gegensatz zu dem, was wir erwarten könnten, wird es nicht unbedingt den Primärschlüssel der Tabelle auswählen, sondern den ersten eindeutigen Index, den es findet, abhängig von der Art des Index und dem Namen des Index. Wir haben Strategien besprochen, um sicherzustellen, dass Access den richtigen eindeutigen Index auswählt. Wir haben uns die SQL-Ansicht angesehen, die normalerweise keine Indizes hat, und eine Methode besprochen, mit der wir Access darüber informieren können, wie eine SQL-Ansicht oder eine Tabelle ohne Primärschlüssel verschlüsselt werden muss, sodass wir mehr Kontrolle darüber haben, wie Access die Aktualisierungen handhabt diese ODBC-verknüpften Tabellen.

Im nächsten Artikel werden wir uns ansehen, wie Access tatsächlich Aktualisierungen an den Daten durchführt, wenn Benutzer Änderungen über die Access-Abfrage oder Datensatzquelle vornehmen.

Unsere Zugangsexperten stehen Ihnen zur Verfügung. Rufen Sie uns unter 773-809-5456 an oder senden Sie uns eine E-Mail an [email protected].