Migrieren einer Access-Datenbank zu SQL Server

Vorbereitende Schritte

Die folgenden Abschnitte enthalten Hintergrundinformationen und andere Informationen, die Ihnen beim Einstieg helfen.

Informationen zu geteilten Datenbanken

Alle Access-Datenbankobjekte können sich entweder in einer Datenbankdatei oder in zwei Datenbankdateien befinden: einer Front-End-Datenbank und einer Back-End-Datenbank. Dies wird als Aufteilen der Datenbank bezeichnet und soll die Freigabe in einer Netzwerkumgebung erleichtern. Die Back-End-Datenbankdatei darf nur Tabellen und Beziehungen enthalten. Die Front-End-Datei darf nur alle anderen Objekte enthalten, einschließlich Formularen, Berichten, Abfragen, Makros, VBA-Modulen und verknüpften Tabellen mit der Back-End-Datenbank. Wenn Sie eine Access-Datenbank migrieren, ähnelt sie einer geteilten Datenbank, da SQL Server als neues Back-End für die Daten fungiert, die sich jetzt auf einem Server befinden.

Daher können Sie die Access-Front-End-Datenbank weiterhin mit verknüpften Tabellen mit den SQL Server Tabellen verwalten. Effektiv können Sie die Vorteile der schnellen Anwendungsentwicklung, die eine Access-Datenbank bietet, sowie die Skalierbarkeit von SQL Server ableiten.

SQL Server Vorteile

Benötigen Sie noch einige Überzeugende, um zu SQL Server zu migrieren? Hier sind einige zusätzliche Vorteile, die Sie berücksichtigen sollten:

Mehr gleichzeitige Benutzer SQL Server kann viel mehr gleichzeitige Benutzer verarbeiten als Access und minimiert den Arbeitsspeicherbedarf, wenn mehr Benutzer hinzugefügt werden.
Erhöhte Verfügbarkeit Mit SQL Server können Sie die Datenbank dynamisch inkrementell oder vollständig sichern, während sie verwendet wird. Demzufolge müssen Sie die Benutzer nicht zum Beenden der Datenbank zwingen, um Daten zu sichern.
Hohe Leistung und Skalierbarkeit Die SQL Server-Datenbank ist in der Regel besser als eine Access-Datenbank, insbesondere bei einer großen Datenbank mit Terabytegröße. Darüber hinaus verarbeitet SQL Server Abfragen viel schneller und effizienter, indem Abfragen parallel verarbeitet werden, wobei mehrere native Threads innerhalb eines einzelnen Prozesses verwendet werden, um Benutzeranforderungen zu verarbeiten.
Verbesserte Sicherheit Mithilfe einer vertrauenswürdigen Verbindung kann SQL Server in die Windows-Systemsicherheit integriert werden, um einen einzigen integrierten Zugriff auf das Netzwerk und die Datenbank bereitzustellen, wobei das Beste aus beiden Sicherheitssystemen verwendet wird. Dies erleichtert die Verwaltung komplexer Sicherheitsschemas. SQL Server ist der ideale Speicher für vertrauliche Informationen wie Sozialversicherungsnummern, Gutschriften Karte Daten und vertrauliche Adressen.
Sofortige Wiederherstellbarkeit Wenn das Betriebssystem abstürzt oder die Stromversorgung ausfällt, können SQL Server die Datenbank innerhalb weniger Minuten und ohne Eingriff des Datenbankadministrators automatisch in einen konsistenten Zustand wiederherstellen.
Verwendung von VPN Der Zugriff und virtuelle private Netzwerke (VPN) kommen nicht aus. Mit SQL Server können Remotebenutzer jedoch weiterhin die Access-Front-End-Datenbank auf einem Desktop und das SQL Server Back-End hinter der VPN-Firewall verwenden.
Azure SQL Server Zusätzlich zu den Vorteilen der SQL Server bietet dynamische Skalierbarkeit ohne Ausfallzeiten, intelligente Optimierung, globale Skalierbarkeit und Verfügbarkeit, Beseitigung von Hardwarekosten und reduzierte Verwaltung.

Auswählen der besten Azure SQL Server-Option

Wenn Sie zu Azure SQL Server migrieren, stehen drei Optionen zur Auswahl, die jeweils unterschiedliche Vorteile bieten:

Einzeldatenbank/Pools für elastische Datenbanken Diese Option verfügt über einen eigenen Satz von Ressourcen, die über einen SQL-Datenbank-Server verwaltet werden. Eine Einzeldatenbank ist wie eine eigenständige Datenbank in SQL Server. Sie können auch einen Pool für elastische Datenbanken hinzufügen, bei dem es sich um eine Sammlung von Datenbanken mit gemeinsam genutzten Ressourcen handelt, die über den SQL-Datenbank-Server verwaltet werden. Die am häufigsten verwendeten SQL Server Features sind mit integrierten Sicherungen, Patches und Wiederherstellungen verfügbar. Es gibt jedoch keine garantierte genaue Wartungszeit, und die Migration von SQL Server kann schwierig sein.
Verwaltete instance Diese Option ist eine Sammlung von System- und Benutzerdatenbanken mit einem freigegebenen Satz von Ressourcen. Eine verwaltete instance ist wie eine instance der SQL Server-Datenbank, die mit SQL Server lokal kompatibel ist. Eine verwaltete instance verfügt über integrierte Sicherungen, Patches und Wiederherstellungen und ist einfach von SQL Server zu migrieren. Es gibt jedoch eine kleine Anzahl von SQL Server Features, die nicht verfügbar sind, und es gibt keine garantierte genaue Wartungszeit.
Virtueller Azure-Computer Mit dieser Option können Sie SQL Server auf einem virtuellen Computer in der Azure-Cloud ausführen. Sie haben die vollständige Kontrolle über die SQL Server-Engine und einen einfachen Migrationspfad. Sie müssen jedoch Ihre Sicherungen, Patches und Wiederherstellungen verwalten.

Weitere Informationen finden Sie unter Auswählen des Datenbankmigrationspfads zu Azure und Was ist Azure SQL?.

Erste Schritte

Es gibt einige Probleme, die Sie im Voraus beheben können, um den Migrationsprozess zu optimieren, bevor Sie SSMA ausführen:

Hinzufügen von Tabellenindizes und Primärschlüsseln Stellen Sie sicher, dass jede Access-Tabelle über einen Index und einen Primärschlüssel verfügt. SQL Server erfordert, dass alle Tabellen mindestens einen Index haben und eine verknüpfte Tabelle über einen Primärschlüssel verfügt, wenn die Tabelle aktualisiert werden kann.
Überprüfen von Primär-/Fremdschlüsselbeziehungen Stellen Sie sicher, dass diese Beziehungen auf Feldern mit konsistenten Datentypen und Größen basieren. SQL Server unterstützt keine verknüpften Spalten mit unterschiedlichen Datentypen und Größen in Fremdschlüsseleinschränkungen.
Entfernen der Spalte "Anlage" SSMA migriert keine Tabellen, die die Spalte Anlage enthalten.

Führen Sie vor dem Ausführen von SSMA die folgenden ersten Schritte aus.

Schließen Sie die Access-Datenbank.
Stellen Sie sicher, dass die aktuellen Benutzer, die mit der Datenbank verbunden sind, auch die Datenbank schließen.
Wenn die Datenbank .mdb Dateiformat aufweist, entfernen Sie sicherheit auf Benutzerebene.
Sichern Sie Ihre Datenbank. Weitere Informationen finden Sie unter Schützen Ihrer Daten mit Sicherungs- und Wiederherstellungsprozessen.

Tipp Erwägen Sie die Installation Microsoft SQL Server Express Edition auf Ihrem Desktop, die bis zu 10 GB unterstützt und eine kostenlose und einfachere Möglichkeit zum Durchlaufen und Überprüfen Ihrer Migration darstellt. Wenn Sie eine Verbindung herstellen, verwenden Sie LocalDB als Datenbank-instance.

Tipp Verwenden Sie nach Möglichkeit eine eigenständige Version von Access. Wenn Sie nur Microsoft 365 verwenden können, verwenden Sie die Access 2010-Datenbank-Engine, um Ihre Access-Datenbank bei Verwendung von SSMA zu migrieren. Weitere Informationen finden Sie unter Microsoft Access Database Engine 2010 Redistributable.

Ausführen von SSMA

Microsoft bietet Microsoft SQL Server Migration Assistant (SSMA), um die Migration zu vereinfachen. SSMA migriert hauptsächlich Tabellen und Auswahlabfragen ohne Parameter. Formulare, Berichte, Makros und VBA-Module werden nicht konvertiert. Die SQL Server Metadata Explorer zeigt Ihre Access-Datenbankobjekte und SQL Server Objekte an, sodass Sie den aktuellen Inhalt beider Datenbanken überprüfen können. Diese beiden Verbindungen werden in Ihrer Migrationsdatei gespeichert, wenn Sie sich entscheiden, in Zukunft weitere Objekte zu übertragen.

Hinweis Abhängig von der Größe Ihrer Datenbankobjekte und der Menge der zu übertragenden Daten kann der Migrationsprozess einige Zeit in Anspruch nehmen.

Um eine Datenbank mit SSMA zu migrieren, laden Sie zuerst die Software herunter, und installieren Sie sie, indem Sie auf die heruntergeladene MSI-Datei doppelklicken. Stellen Sie sicher, dass Sie die entsprechende 32- oder 64-Bit-Version für Ihren Computer installieren.
Öffnen Sie nach der Installation von SSMA es auf Ihrem Desktop, vorzugsweise auf dem Computer mit der Access-Datenbankdatei.

Sie können sie auch auf einem Computer öffnen, der über das Netzwerk in einem freigegebenen Ordner Zugriff auf die Access-Datenbank hat.
Befolgen Sie die ersten Anweisungen in SSMA, um grundlegende Informationen wie den SQL Server Speicherort, die Access-Datenbank und die zu migrierenden Objekte, Verbindungsinformationen und die Erstellung verknüpfter Tabellen bereitzustellen.
Wenn Sie zu SQL Server 2016 oder höher migrieren und eine verknüpfte Tabelle aktualisieren möchten, fügen Sie eine rowversion-Spalte hinzu, indem Sie "Tools überprüfen" > Projekteinstellungen > Allgemein auswählen.

Das Rowversion-Feld trägt dazu bei, Datensatzkonflikte zu vermeiden. Access verwendet dieses Rowversion-Feld in einer SQL Server verknüpften Tabelle, um zu bestimmen, wann der Datensatz zuletzt aktualisiert wurde. Wenn Sie das Rowversion-Feld zu einer Abfrage hinzufügen, verwendet Access es außerdem, um die Zeile nach einem Aktualisierungsvorgang erneut auszuwählen. Dies verbessert die Effizienz, indem Schreibkonflikte und Datensatzlöschungsszenarien vermieden werden, die auftreten können, wenn Access andere Ergebnisse als die ursprüngliche Übermittlung erkennt, z. B. bei Gleitkommazahlen-Datentypen und Triggern, die Spalten ändern. Vermeiden Sie jedoch die Verwendung des Rowversion-Felds in Formularen, Berichten oder VBA-Code. Weitere Informationen finden Sie unter rowversion.

Hinweis Vermeiden Sie die Verwechslung von rowversion mit Zeitstempeln. Obwohl der Schlüsselwort (keyword) Timestamp ein Synonym für rowversion in SQL Server ist, können Sie rowversion nicht als Möglichkeit zum Zeitstempeln einer Dateneingabe verwenden.
Um genaue Datentypen festzulegen, wählen Sie Tools überprüfen > Projekteinstellungen > Typzuordnung aus. Wenn Sie beispielsweise nur englischen Text speichern, können Sie den Datentyp varchar anstelle von nvarchar verwenden.

Konvertieren von Objekten

SSMA konvertiert Access-Objekte in SQL Server Objekte, kopiert die Objekte jedoch nicht sofort. SSMA stellt eine Liste der folgenden zu migrierenden Objekte bereit, damit Sie entscheiden können, ob Sie sie in SQL Server Datenbank verschieben möchten:

Tabellen und Spalten
Wählen Sie Abfragen ohne Parameter aus.
Primär- und Fremdschlüssel
Indizes und Standardwerte
Check-Einschränkungen (Spalteneigenschaft der Länge null zulassen, Spaltenvalidierungsregel, Tabellenüberprüfung zulassen)

Als bewährte Methode sollten Sie den SSMA-Bewertungsbericht verwenden, in dem die Konvertierungsergebnisse angezeigt werden, einschließlich Fehlern, Warnungen, Informationsmeldungen, Zeitschätzungen für die Durchführung der Migration und einzelne Schritte zur Fehlerkorrektur, die ausgeführt werden müssen, bevor Sie die Objekte tatsächlich verschieben.

Beim Konvertieren von Datenbankobjekten werden die Objektdefinitionen aus den Access-Metadaten in eine entsprechende Transact-SQL-Syntax (T-SQL) konvertiert und dann in das Projekt geladen. Anschließend können Sie die SQL Server- oder SQL Azure-Objekte und deren Eigenschaften mithilfe von SQL Server oder SQL Azure Metadata Explorer anzeigen.

Befolgen Sie diese Anleitung, um Objekte in SQL Server zu konvertieren, zu laden und zu migrieren.

Tipp Nachdem Sie Ihre Access-Datenbank erfolgreich migriert haben, speichern Sie die Projektdatei zur späteren Verwendung, damit Sie Ihre Daten erneut zum Testen oder zur endgültigen Migration migrieren können.

Verknüpfen von Tabellen

Erwägen Sie, die neueste Version der SQL Server OLE DB- und ODBC-Treiber zu installieren, anstatt die nativen SQL Server Treiber zu verwenden, die im Lieferumfang von Windows enthalten sind. Die neueren Treiber sind nicht nur schneller, sondern unterstützen auch neue Features in Azure SQL, die die vorherigen Treiber nicht. Sie können die Treiber auf jedem Computer installieren, auf dem die konvertierte Datenbank verwendet wird. Weitere Informationen finden Sie unter Microsoft OLE DB Driver 18 for SQL Server und Microsoft ODBC Driver 17 for SQL Server.

Nachdem Sie die Access-Tabellen migriert haben, können Sie eine Verknüpfung mit den Tabellen in SQL Server die nun Ihre Daten hostet. Durch die direkte Verknüpfung von Access erhalten Sie auch eine einfachere Möglichkeit, Ihre Daten anzuzeigen, anstatt die komplexeren SQL Server-Verwaltungstools zu verwenden. Sie können verknüpfte Daten abhängig von den Berechtigungen abfragen und bearbeiten, die von Ihrem SQL Server Datenbankadministrator eingerichtet wurden.

Hinweis Wenn Sie einen ODBC-DSN erstellen, wenn Sie während des Verknüpfungsprozesses eine Verknüpfung mit Ihrer SQL Server Datenbank herstellen, erstellen Sie entweder denselben DSN auf allen Computern, die die neue Anwendung verwenden, oder verwenden Sie programmgesteuert den in der DSN-Datei gespeicherten Verbindungszeichenfolge.

Weitere Informationen finden Sie unter Verknüpfen mit oder Importieren von Daten aus einer Azure SQL Serverdatenbank und Importieren oder Verknüpfen von Daten in einer SQL Server-Datenbank.

Tipp Vergessen Sie nicht, den Manager für verknüpfte Tabellen in Access zu verwenden, um Tabellen bequem zu aktualisieren und neu zu verknüpfen. Weitere Informationen finden Sie unter Verwalten verknüpfter Tabellen.

Testen und überarbeiten

In den folgenden Abschnitten werden häufige Probleme beschrieben, die während der Migration auftreten können, sowie deren Behandlung.

Abfragen

Nur Auswahlabfragen werden konvertiert. andere Abfragen sind dies nicht, einschließlich Select-Abfragen, die Parameter annehmen. Einige Abfragen werden möglicherweise nicht vollständig konvertiert, und SSMA meldet Abfragefehler während des Konvertierungsprozesses. Sie können Objekte, die nicht konvertiert werden, mithilfe der T-SQL-Syntax manuell bearbeiten. Syntaxfehler können auch eine manuelle Konvertierung von Access-spezifischen Funktionen und Datentypen in SQL Server erfordern. Weitere Informationen finden Sie unter Vergleich von Access SQL und SQL Server TSQL.

Datentypen

Access und SQL Server weisen ähnliche Datentypen auf, beachten Sie jedoch die folgenden potenziellen Probleme.

Große Zahl Der Datentyp "Große Zahl" speichert einen nicht monetären numerischen Wert und ist mit dem SQL-Datentyp bigint kompatibel. Sie können diesen Datentyp verwenden, um große Zahlen effizient zu berechnen, aber er erfordert die Verwendung des Access 16 (16.0.7812 oder höher) ACCDB-Datenbankdateiformats und ist mit der 64-Bit-Version von Access besser. Weitere Informationen finden Sie unter Verwenden des Datentyps "Große Zahl " und Auswählen zwischen der 64-Bit- oder 32-Bit-Version von Office.

Ja/Nein Standardmäßig wird eine Access Yes/No-Spalte in ein SQL Server Bitfeld konvertiert. Um Datensatzsperren zu vermeiden, stellen Sie sicher, dass das Bitfeld so festgelegt ist, dass NULL-Werte nicht zulässig sind. In SSMA können Sie die Bitspalte auswählen, um die Eigenschaft Nullen zulassen auf NO festzulegen. Verwenden Sie in TSQL die ANWEISUNGEN CREATE TABLE oder ALTER TABLE .

Datum und Uhrzeit Es gibt mehrere Überlegungen zu Datum und Uhrzeit:

Wenn der Kompatibilitätsgrad der Datenbank 130 (SQL Server 2016) oder höher beträgt und eine verknüpfte Tabelle mindestens eine datetime- oder datetime2-Spalte enthält, gibt die Tabelle möglicherweise die Meldung zurück, die in den Ergebnissen #deleted. Weitere Informationen finden Sie unter Access linked table to SQL-Server database returns #deleted.for more information, see Access linked table to SQL-Server database returns #deleted.
Verwenden Sie den Access Date/Time-Datentyp, um dem datetime-Datentyp zuzuordnen. Verwenden Sie den Access Date/Time Extended-Datentyp, um dem datetime2-Datentyp zuzuordnen, der einen größeren Datums- und Uhrzeitbereich aufweist. Weitere Informationen finden Sie unter Verwenden des Date/Time Extended-Datentyps.
Berücksichtigen Sie beim Abfragen von Datumsangaben in SQL Server sowohl die Uhrzeit als auch das Datum. Beispiel:
- DateOrdered Zwischen dem 01.01.19 und dem 31.01.19 enthält möglicherweise nicht alle Bestellungen.
- DateOrdered Zwischen 1/1/19 00:00:00 AM Und 1/31/19 23:59:59 pm enthält alle Bestellungen.

Anlage Der Attachment-Datentyp speichert eine Datei in der Access-Datenbank. In SQL Server können Sie mehrere Optionen in Betracht ziehen. Sie können die Dateien aus der Access-Datenbank extrahieren und dann Links zu den Dateien in Ihrer SQL Server-Datenbank speichern. Alternativ können Sie FILESTREAM, FileTables oder RBS (Remote BLOB Store) verwenden, um Anlagen in der SQL Server-Datenbank zu speichern.

Hyperlink Access-Tabellen enthalten Linkspalten, die SQL Server nicht unterstützt. Standardmäßig werden diese Spalten in nvarchar(max)-Spalten in SQL Server konvertiert. Sie können die Zuordnung jedoch anpassen, um einen kleineren Datentyp auszuwählen. In Ihrer Access-Lösung können Sie das Hyperlinkverhalten weiterhin in Formularen und Berichten verwenden, wenn Sie die Hyperlink-Eigenschaft für das Steuerelement auf true festlegen.

Mehrwertiges Feld Das mehrwertige Access-Feld wird in SQL Server als ntext-Feld konvertiert, das den durch Trennzeichen getrennten Satz von Werten enthält. Da SQL Server keinen mehrwertigen Datentyp unterstützt, der eine m:n-Beziehung modelliert, kann zusätzlicher Entwurfs- und Konvertierungsaufwand erforderlich sein.

Weitere Informationen zum Zuordnen von Access- und SQL Server-Datentypen finden Sie unter Vergleichen von Datentypen.

Hinweis Mehrwertige Felder werden nicht konvertiert.

Weitere Informationen finden Sie unter Datums- und Uhrzeittypen, Zeichenfolgen- und Binärtypen und Numerische Typen.

Visual Basic

Obwohl VBA von SQL Server nicht unterstützt wird, beachten Sie die folgenden möglichen Probleme:

VBA-Funktionen in Abfragen Zugriffsabfragen unterstützen VBA-Funktionen für Daten in einer Abfragespalte. Access-Abfragen, die VBA-Funktionen verwenden, können jedoch nicht auf SQL Server ausgeführt werden, sodass alle angeforderten Daten zur Verarbeitung an Microsoft Access übergeben werden. In den meisten Fällen sollten diese Abfragen in Pass-Through-Abfragen konvertiert werden.

Benutzerdefinierte Funktionen in Abfragen Microsoft Access-Abfragen unterstützen die Verwendung von Funktionen, die in VBA-Modulen definiert sind, um an sie übergebene Daten zu verarbeiten. Abfragen können eigenständige Abfragen, SQL-Anweisungen in Formular-/Berichtsdatensatzquellen, Datenquellen von Kombinationsfeldern und Listenfeldern in Formularen, Berichten und Tabellenfeldern sowie Standard- oder Validierungsregelausdrücke sein. SQL Server können diese benutzerdefinierten Funktionen nicht ausführen. Möglicherweise müssen Sie diese Funktionen manuell umgestalten und auf SQL Server in gespeicherte Prozeduren konvertieren.

Optimieren der Leistung

Die bei weitem wichtigste Möglichkeit, die Leistung mit Ihren neuen Back-End-SQL Server zu optimieren, besteht darin, zu entscheiden, wann lokale oder Remoteabfragen verwendet werden sollen. Wenn Sie Ihre Daten zu SQL Server migrieren, wechseln Sie auch von einem Dateiserver zu einem Client-Server-Datenbankmodell für Computing. Befolgen Sie diese allgemeinen Richtlinien:

Führen Sie kleine, schreibgeschützte Abfragen auf dem Client aus, um den schnellen Zugriff zu ermöglichen.
Führen Sie lange Lese-/Schreibabfragen auf dem Server aus, um die höhere Verarbeitungsleistung zu nutzen.
Minimieren Sie den Netzwerkdatenverkehr mit Filtern und Aggregation, um nur die benötigten Daten zu übertragen.

Optimieren der Leistung im Clientserver-Datenbankmodell

Weitere Informationen finden Sie unter Erstellen einer Passthrough-Abfrage.

Im Folgenden sind weitere empfohlene Richtlinien aufgeführt.

Platzieren von Logik auf dem Server Ihre Anwendung kann auch Ansichten, benutzerdefinierte Funktionen, gespeicherte Prozeduren, berechnete Felder und Trigger verwenden, um Anwendungslogik, Geschäftsregeln und Richtlinien, komplexe Abfragen, Datenüberprüfung und Referenzintegritätscode auf dem Server und nicht auf dem Client zu zentralisieren und gemeinsam zu nutzen. Fragen Sie sich: Kann diese Abfrage oder Aufgabe besser und schneller auf dem Server ausgeführt werden? Testen Sie abschließend jede Abfrage, um eine optimale Leistung sicherzustellen.

Verwenden von Ansichten in Formularen und Berichten Gehen Sie in Access wie folgt vor:

Verwenden Sie für Formulare eine SQL-Ansicht für ein schreibgeschütztes Formular und eine SQL-indizierte Sicht für ein Lese-/Schreibformular als Datensatzquelle.
Verwenden Sie für Berichte eine SQL-Sicht als Datensatzquelle. Erstellen Sie jedoch eine separate Ansicht für jeden Bericht, damit Sie einen bestimmten Bericht einfacher aktualisieren können, ohne dass sich dies auf andere Berichte auswirkt.

Minimieren des Ladens von Daten in einem Formular oder Bericht Zeigen Sie keine Daten an, bis der Benutzer danach fragt. Lassen Sie z. B. die Recordsource-Eigenschaft leer, lassen Sie Benutzer einen Filter in Ihrem Formular auswählen, und füllen Sie dann die recordsource-Eigenschaft mit Ihrem Filter auf. Oder verwenden Sie die where-Klausel von DoCmd.OpenForm und DoCmd.OpenReport, um die genauen Datensätze anzuzeigen, die vom Benutzer benötigt werden. Erwägen Sie, die Datensatznavigation zu deaktivieren.

Vorsicht bei heterogenen Abfragen Vermeiden Sie das Ausführen einer Abfrage, die eine lokale Access-Tabelle und SQL Server verknüpfte Tabelle kombiniert, die manchmal auch als Hybridabfrage bezeichnet wird. Diese Art von Abfrage erfordert weiterhin Access, um alle SQL Server Daten auf den lokalen Computer herunterzuladen und dann die Abfrage auszuführen. Die Abfrage wird nicht in SQL Server ausgeführt.

Verwendung von lokalen Tabellen Erwägen Sie die Verwendung lokaler Tabellen für Daten, die sich selten ändern, z. B. die Liste der Bundesstaaten oder Provinzen in einem Land oder einer Region. Statische Tabellen werden häufig zum Filtern verwendet und können im Access-Front-End besser funktionieren.

Weitere Informationen finden Sie unter Datenbankoptimierungsratgeber, Verwenden der Leistungsanalyse zum Optimieren einer Access-Datenbank und Optimieren von mit SQL Server verknüpften Microsoft Office Access-Anwendungen.