Migrieren einer Access-Datenbank zu SQL Server

Gilt für

Access für Microsoft 365 Access 2024 Access 2021 Access 2019 Access 2016

Wir alle haben Grenzen, und eine Access-Datenbank ist da keine Ausnahme. Beispielsweise hat eine Access-Datenbank eine Größenbeschränkung von 2 GB und kann nicht mehr als 255 gleichzeitige Benutzer unterstützen. Wenn es also an der Zeit ist, Ihre Access-Datenbank auf die nächste Ebene zu bringen, können Sie zu SQL Server migrieren. SQL Server (lokal oder in der Azure Cloud) unterstützt größere Datenmengen, mehr gleichzeitige Benutzer und verfügt über eine größere Kapazität als die JET/ACE-Datenbankengine. Dieses Handbuch bietet Ihnen einen reibungslosen Start in Ihre SQL Server-Reise, hilft, von Ihnen erstellte Access-Front-End-Lösungen zu erhalten, und motiviert Sie hoffentlich, Access für zukünftige Datenbanklösungen zu verwenden. Verwenden Sie den Microsoft SQL Server Migration Assistant (SSMA), um erfolgreich zu migrieren, und führen Sie die folgenden Phasen aus.

Die Phasen der Datenbankmigration zu SQL Server

Bevor Sie beginnen

Die folgenden Abschnitte enthalten Hintergrundinformationen und andere Informationen, die Ihnen den Einstieg erleichtern.

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 gemeinsame Nutzung 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 Formulare, Berichte, Abfragen, Makros, VBA-Module und verknüpfte Tabellen zur Back-End-Datenbank. Die Migration einer Access-Datenbank ähnelt 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 Front-End-Access-Datenbank weiterhin mit verknüpften Tabellen zu den SQL Server-Tabellen verwalten. Sie können die Vorteile einer schnellen Anwendungsentwicklung, die eine Access-Datenbank bietet, zusammen mit der Skalierbarkeit von SQL Server nutzen.

Vorteile von SQL Server

Benötigen Sie weitere Überzeugungsarbeit, um zu SQL Server zu migrieren? Hier sind einige zusätzliche Vorteile, die Sie bedenken sollten:

Mehr gleichzeitige Benutzer SQL Server kann viel mehr gleichzeitige Benutzer als Access verarbeiten und minimiert den Speicherbedarf, wenn weitere Benutzer hinzugefügt werden.
Erhöhte Verfügbarkeit Mit SQL Server können Sie die Datenbank dynamisch sichern, entweder inkrementell oder vollständig, 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 schneidet in der Regel besser ab als eine Access-Datenbank, insbesondere bei einer großen Datenbank mit Terabyte-Größe. Außerdem verarbeitet SQL Server Abfragen wesentlich schneller und effizienter, indem Abfragen parallel verarbeitet werden und mehrere systemeigene Threads innerhalb eines einzigen Prozesses verwendet werden, um Benutzeranforderungen zu verarbeiten.
Verbesserte Sicherheit Über eine vertrauenswürdige Verbindung lässt sich SQL Server in die Windows-Systemsicherheit integrieren, um einen einzigen integrierten Zugriff auf das Netzwerk und die Datenbank bereitzustellen, bei dem die Vorteile beider Sicherheitssysteme zum Einsatz kommen. Dies erleichtert die Verwaltung komplexer Sicherheitsschemata erheblich. SQL Server ist der ideale Speicher für vertrauliche Informationen wie Sozialversicherungsnummern, Kredit- Karte Daten und vertrauliche Adressen.
Sofortige Wiederherstellbarkeit Bei einem Absturz des Betriebssystems oder einem Stromausfall kann SQL Server die Datenbank automatisch binnen Minuten und ohne Eingriff des Datenbankadministrators in einen konsistenten Zustand versetzen.
Verwendung von VPN Access und Virtual Private Networks (VPN) vertragen sich nicht. Bei 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 bietet zusätzlich zu den Vorteilen von SQL Server dynamische Skalierbarkeit ohne Ausfallzeiten, intelligente Optimierung, globale Skalierbarkeit und Verfügbarkeit, Eliminierung von Hardwarekosten und reduzierten Verwaltungsaufwand.

Auswählen der besten Option für Azure SQL Server

Wenn Sie eine Migration zu Azure SQL Server durchführen, stehen Ihnen 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 einzelne Datenbank 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 einem freigegebenen Satz von Ressourcen handelt, die über den SQL-Datenbank-Server verwaltet werden. Die am häufigsten verwendeten SQL Server Features sind mit integrierten Backups, Patches und Wiederherstellung verfügbar. Es gibt jedoch keine garantierte genaue Wartungszeit, und die Migration von SQL Server kann schwierig sein.
Managed instance Bei dieser Option handelt es sich um eine Sammlung von System- und Benutzerdatenbanken mit einem gemeinsam genutzten Satz von Ressourcen. Ein verwaltetes instance ist wie eine instance der SQL Server Datenbank, die mit SQL Server lokalen Systemen hochkompatibel ist. Eine verwaltete Instance verfügt über integrierte Sicherungen, Patches und Wiederherstellung und ist einfach von SQL Server zu migrieren. Es gibt jedoch eine kleine Anzahl von SQL Server Features, die nicht verfügbar sind und 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. Aber Sie müssen 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 Vorfeld beheben können, um den Migrationsprozess vor dem Ausführen von SSMA zu optimieren:

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. In SQL Server müssen alle Tabellen über mindestens einen Index verfügen, und eine verknüpfte Tabelle muss über einen Primärschlüssel verfügen, wenn die Tabelle aktualisiert werden kann.
Primär-/Fremdschlüsselbeziehungen überprüfen Stellen Sie sicher, dass diese Beziehungen auf Feldern mit einheitlichen 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 Anlagenspalte SSMA migriert keine Tabellen, die die Spalte "Anlagen" enthalten.

Führen Sie die folgenden ersten Schritte aus, bevor Sie SSMA ausführen.

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

Tipp Erwägen Sie, die Microsoft SQL Server Express Edition auf Ihrem Desktop zu installieren, die bis zu 10 GB unterstützt und eine kostenlose und einfachere Möglichkeit ist, Ihre Migration durchzuführen und zu überprüfen. Wenn Sie eine Verbindung herstellen, verwenden Sie LocalDB als Datenbank-Instance.

Tipp Verwenden Sie, wenn möglich, eine eigenständige Version von Access.

Ausführen von SSMA

Microsoft stellt den Microsoft Microsoft SQL Server Migration Assistant (SSMA) bereit, um die Migration zu vereinfachen. SSMA migriert hauptsächlich Tabellen und Auswahlabfragen ohne Parameter. Formulare, Berichte, Makros und VBA-Module werden nicht konvertiert. Im SQL Server-Metadaten-Explorer werden Ihre Access-Datenbankobjekte und SQL Server-Objekte angezeigt, sodass Sie den aktuellen Inhalt beider Datenbanken überprüfen können. Diese beiden Verbindungen werden in Ihrer Migrationsdatei gespeichert, falls Sie in Zukunft weitere Objekte übertragen möchten.

Hinweis Der Migrationsprozess kann je nach Größe der Datenbankobjekte und der Menge der zu übertragenden Daten 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 richtige 32- oder 64-Bit-Version für Ihren Computer installieren.
Öffnen Sie SSMA nach der Installation auf Ihrem Desktop, vorzugsweise von dem Computer mit der Access-Datenbankdatei.
Sie können es auch auf einem Computer mit Netzwerkzugriff auf die Access-Datenbank in einem freigegebenen Ordner öffnen.
Befolgen Sie die Anfangsanweisungen in SSMA, um grundlegende Informationen bereitzustellen, z. B. den Speicherort von SQL Server, die Access-Datenbank und die zu migrierenden Objekte, Verbindungsinformationen und ob Sie verknüpfte Tabellen erstellen möchten.
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 "Extras überprüfen">Projekteinstellungen>allgemein auswählen.
Das Feld ROWVERSION hilft, Datensatzkonflikte zu vermeiden. Access verwendet dieses ROWVERSION-Feld in einer mit SQL Server verknüpften Tabelle, um zu bestimmen, wann der Datensatz zuletzt aktualisiert wurde. Wenn Sie das Feld ROWVERSION zu einer Abfrage hinzufügen, verwendet Access es auch, um die Zeile nach einem Aktualisierungsvorgang erneut auszuwählen. Dies verbessert die Effizienz, indem Schreibkonfliktfehler und Datensatzlöschszenarien vermieden werden, die auftreten können, wenn Access unterschiedliche Ergebnisse zur ursprünglichen Übermittlung erkennt, wie sie z. B. bei Gleitkommazahl-Datentypen und Triggern auftreten können, die Spalten ändern. Vermeiden Sie jedoch die Verwendung des Felds ROWVERSION in Formularen, Berichten oder VBA-Code. Weitere Informationen finden Sie unter ROWVERSION.
Hinweis Verwechseln Sie RowVersion nicht mit Zeitstempeln. Obwohl das Schlüsselwort (keyword)-Zeitstempel ein Synonym für ROWVERSION in SQL Server ist, können Sie ROWVERSION nicht als Zeitstempel für einen Dateneintrag verwenden.
Um genaue Datentypen festzulegen, wählen Sie Tools> überprüfenProjekteinstellungen>Typzuordnung. Wenn Sie z. B. nur englischen Text speichern, können Sie den varchar-Datentyp anstelle des nvarchar-Datentyps verwenden.

Konvertieren von Objekten

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

Tabellen und Spalten
Wählen Sie Abfragen ohne Parameter aus.
Primär- und Fremdschlüssel
Indizes und Standardwerte
Einschränkungen prüfen (Spalteneigenschaft Null zulassen, Spaltenvalidierungsregel, Tabellenvalidierung)

Als bewährte Methode verwenden Sie den SSMA-Bewertungsbericht, der die Konvertierungsergebnisse anzeigt, einschließlich Fehler, Warnungen, Informationsmeldungen, Zeitschätzungen für die Durchführung der Migration und einzelner Schritte zur Fehlerbehebung, die Sie ausführen müssen, bevor Sie die Objekte tatsächlich verschieben.

Beim Konvertieren von Datenbankobjekten werden die Objektdefinitionen aus den Access-Metadaten in die entsprechende Transact-SQL-SYNTAX (T-SQL) konvertiert und diese Informationen 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-Metadaten-Explorer anzeigen.

Folgen Sie dieser Anleitung, um Objekte zu 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 zum Testen oder zur endgültigen Migration erneut migrieren können.

Tabellen verknüpfen

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

Nachdem Sie die Access-Tabellen migriert haben, können Sie eine Verknüpfung mit den Tabellen in SQL Server herstellen, die jetzt als Host für Ihre Daten dienen. Die direkte Verknüpfung aus Access ermöglicht es Ihnen auch, Ihre Daten einfacher anzuzeigen, als die komplexeren SQL Server-Verwaltungstools zu verwenden. Sie können verknüpfte Daten abhängig von den Berechtigungen Abfragen und bearbeiten, die Ihr SQL Server-Datenbankadministrator eingerichtet hat.

Hinweis Wenn Sie beim Erstellen eines ODBC-DSN während des Verknüpfungsvorgangs eine Verknüpfung mit Ihrer SQL Server-Datenbank erstellen, erstellen Sie denselben DSN auf allen Computern, die die neue Anwendung verwenden, oder programmgesteuert die in der DSN-Datei gespeicherten Verbindungszeichenfolge.

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

Tipp Vergessen Sie nicht, den Tabellenverknüpfungs-Manager 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, und deren Behebung.

Abfragen

Nur Auswahlabfragen werden konvertiert. Andere Abfragen sind es nicht, einschließlich Auswahlabfragen, die Parameter akzeptieren. 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, manuell bearbeiten, indem Sie die T-SQL-Syntax verwenden. Syntaxfehler können auch eine manuelle Konvertierung von Access-spezifischen Funktionen und Datentypen in SQL Server erforderlich machen. 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-bigint-Datentyp kompatibel. Sie können diesen Datentyp verwenden, um große Zahlen effizient zu berechnen, aber er erfordert die Verwendung des ACCDB-Datenbankdateiformats von Access 16 (16.0.7812 oder höher), und er funktioniert besser mit der 64-Bit-Version von Access. Weitere Informationen finden Sie unter Verwenden des Datentyps "Große Zahl " und Wählen zwischen der 64-Bit- oder 32-Bit-Version von Office.

Ja/Nein Standardmäßig wird eine Access Ja/Nein-Spalte in ein SQL Server-Bitfeld konvertiert. Um Datensatzsperren zu vermeiden, stellen Sie sicher, dass das Bitfeld so eingestellt ist, dass NULL-Werte nicht zulässig sind. IN SSMA können Sie die Bitspalte auswählen, um die Eigenschaft "NULL-Werte 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 ist und eine oder mehrere datetime- oder datetime2-Spalten enthält, gibt die Tabelle möglicherweise die Meldung #deleted in den Ergebnissen zurück. Weitere Informationen finden Sie unter Eine in Access verknüpfte Tabelle mit SQL-Server Datenbank gibt #deleted zurück.
Verwenden Sie den Datentyp "Zugriff auf Datum/Uhrzeit", um ihn dem Datentyp "datetime" zuzuordnen. Verwenden Sie den Datentyp "Access Date/Time Extended", um ihn dem Datentyp "datetime2 " zuzuordnen, der einen größeren Datums- und Uhrzeitbereich aufweist. Weitere Informationen finden Sie unter Verwenden des Datentyps "Erweitertes Datum/Uhrzeit".
Berücksichtigen Sie bei der Abfrage von Datumsangaben in SQL Server sowohl die Uhrzeit als auch das Datum. Beispiel:
- DateOrdered Between 1/1/19 and 1/1/31/19 enthält möglicherweise nicht alle Bestellungen.
- DateOrdered Between 1/1/19 00:00:00 AM And 1/31/19 11:59:59 PM umfasst alle Bestellungen.

Anhang Der Datentyp "Anlage" speichert eine Datei in einer Access-Datenbank. In SQL Server stehen Ihnen mehrere Optionen zur Verfügung. Sie können die Dateien aus der Access-Datenbank extrahieren und dann in Erwägung ziehen, Verknüpfungen zu den Dateien in der SQL Server Datenbank zu speichern. Alternativ können Sie FILESTREAM, FileTables oder den Remote BLOB Store (RBS) verwenden, um Anlagen in der SQL Server-Datenbank gespeichert zu halten.

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

Feld mit mehreren Werten Das mehrwertige Access-Feld wird in SQL Server als ntext-Feld konvertiert, das den durch Trennzeichen getrennten Wertesatz 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 Felder mit mehreren Werten werden nicht konvertiert.

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

Visual Basic

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

VBA-Funktionen in Abfragen Access-Abfragen 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 umgewandelt werden.

Benutzerdefinierte Funktionen in Abfragen Microsoft Access-Abfragen unterstützen die Verwendung von Funktionen, die in VBA-Modulen definiert sind, um die an sie übergebenen 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 Gültigkeitsregelausdrücke sein. SQL Server kann diese benutzerdefinierten Funktionen nicht ausführen. Möglicherweise müssen Sie diese Funktionen manuell neu entwerfen und in gespeicherte Prozeduren auf SQL Server konvertieren.

Optimieren der Leistung

Die bei weitem wichtigste Möglichkeit zur Leistungsoptimierung mit Ihrem neuen Back-End-SQL Server 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 der Verarbeitung. Befolgen Sie diese allgemeinen Richtlinien:

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

Optimieren der Leistung im Clientserver-Datenbankmodell Weitere Informationen finden Sie unter Erstellen einer Pass-Through-Abfrage.

Im Folgenden finden Sie zusätzliche, empfohlene Richtlinien.

Verlegen der Logik auf den 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 referenziellen Integritätscode auf dem Server und nicht auf dem Client zu zentralisieren und gemeinsam zu nutzen. Fragen Sie sich, ob diese Abfrage oder Aufgabe besser und schneller auf dem Server ausgeführt werden kann. 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-Sicht für schreibgeschütztes Formular und eine indizierte SQL-Sicht für Formulare mit Lese-/Schreibzugriff 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 andere Berichte zu beeinträchtigen.

Minimieren des Ladens von Daten in ein Formular oder einen Bericht Daten erst anzeigen, wenn der Benutzer danach fragt. Lassen Sie beispielsweise 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 genau die vom Benutzer benötigten Datensätze anzuzeigen. Erwägen Sie, die Datensatznavigation zu deaktivieren.

Seien Sie vorsichtig bei heterogenen Abfragen Vermeiden Sie das Ausführen einer Abfrage, die eine lokale Access-Tabelle und eine mit SQL Server verknüpfte Tabelle kombiniert, was manchmal auch als Hybridabfrage bezeichnet wird. Dieser Abfragetyp erfordert weiterhin, dass Access alle SQL Server Daten auf den lokalen Computer herunterlädt und dann die Abfrage ausführt. Die Abfrage wird jedoch nicht in SQL Server ausgeführt.

Wann sollten lokale Tabellen verwendet werden? Erwägen Sie die Verwendung lokaler Tabellen für Daten, die sich nur selten ändern, wie die Liste der Bundesstaaten oder Provinzen in einem Land oder einer Region. Statische Tabellen werden häufig zum Filtern verwendet und eignen sich für das Access-Front-End besser.

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