Migrieren Sie eine Access-Datenbank zu SQL Server
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 Stufe zu bringen, können Sie zu SQL Server migrieren. SQL Server (ob lokal oder in der Azure-Cloud) unterstützt größere Datenmengen, mehr gleichzeitige Benutzer und hat eine größere Kapazität als die JET/ACE-Datenbank-Engine. Dieser Leitfaden bietet Ihnen einen reibungslosen Start in Ihre SQL Server-Reise, hilft Ihnen, die von Ihnen erstellten Access-Front-End-Lösungen zu erhalten, und motiviert Sie hoffentlich, Access für zukünftige Datenbanklösungen zu verwenden. Der Upsizing-Assistent wurde in Access 2013 aus Access entfernt, sodass Sie jetzt den Microsoft SQL Server-Migrationsassistenten (SSMA) verwenden können. Befolgen Sie diese Phasen, um erfolgreich zu migrieren.
Bevor Sie beginnen
Die folgenden Abschnitte enthalten Hintergrundinformationen und andere Informationen, die Ihnen den Einstieg erleichtern.
Über geteilte 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 Frontend-Datei darf nur alle anderen Objekte enthalten, einschließlich Formulare, Berichte, Abfragen, Makros, VBA-Module und verknüpfte Tabellen mit der Backend-Datenbank. Wenn Sie eine Access-Datenbank migrieren, ähnelt dies 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 weiterhin die Front-End-Access-Datenbank mit verknüpften Tabellen mit den SQL Server-Tabellen verwalten. Sie können effektiv die Vorteile einer schnellen Anwendungsentwicklung nutzen, die eine Access-Datenbank zusammen mit der Skalierbarkeit von SQL Server bietet.
SQL Server-Vorteile
Brauchen Sie noch etwas Überzeugungsarbeit, um zu SQL Server zu migrieren? Hier sind einige zusätzliche Vorteile, über die Sie nachdenken sollten:
Mehr gleichzeitige Benutzer SQL Server kann viel mehr gleichzeitige Benutzer verarbeiten als Access und minimiert die Speicheranforderungen, wenn mehr 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. Folglich müssen Sie Benutzer nicht zwingen, die Datenbank zu verlassen, um Daten zu sichern.
Hohe Leistung und Skalierbarkeit Die SQL Server-Datenbank ist in der Regel leistungsfähiger als eine Access-Datenbank, insbesondere bei großen Datenbanken im Terabyte-Bereich. Außerdem verarbeitet SQL Server Abfragen viel schneller und effizienter, indem Abfragen parallel verarbeitet werden, wobei mehrere native Threads in einem einzigen Prozess verwendet werden, um Benutzeranforderungen zu verarbeiten.
Verbesserte Sicherheit Über eine vertrauenswürdige Verbindung integriert sich SQL Server in die Windows-Systemsicherheit, um einen einzigen integrierten Zugriff auf das Netzwerk und die Datenbank bereitzustellen, wobei das Beste aus beiden Sicherheitssystemen zum Einsatz kommt. Dies erleichtert die Verwaltung komplexer Sicherheitsschemata erheblich. SQL Server ist der ideale Speicher für vertrauliche Informationen wie Sozialversicherungsnummern, Kreditkartendaten und vertrauliche Adressen.
Sofortige Wiederherstellbarkeit Wenn das Betriebssystem abstürzt oder der Strom ausfällt, kann SQL Server die Datenbank automatisch innerhalb weniger Minuten und ohne Eingreifen des Datenbankadministrators in einem konsistenten Zustand wiederherstellen.
Die Nutzung von VPN- Zugang und Virtual Private Networks (VPN) vertragen sich nicht. Mit SQL Server können Remote-Benutzer jedoch weiterhin die Access-Front-End-Datenbank auf einem Desktop und das SQL Server-Back-End verwenden, das sich hinter der VPN-Firewall befindet.
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 reduzierte Verwaltung.
Wählen Sie die beste Azure SQL Server-Option
Wenn Sie zu Azure SQL Server migrieren, stehen drei Optionen mit jeweils unterschiedlichen Vorteilen zur Auswahl:
Einzeldatenbank/elastische Pools Diese Option verfügt über einen eigenen Satz von Ressourcen, die über einen SQL-Datenbankserver 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 gemeinsam genutzten Ressourcen handelt, die über den SQL-Datenbankserver verwaltet werden. Die am häufigsten verwendeten SQL Server-Funktionen sind mit integrierten Sicherungen, Patches und Wiederherstellung verfügbar. Es gibt jedoch keine garantierte genaue Wartungszeit, und die Migration von SQL Server kann schwierig sein.
Verwaltete Instanz Diese Option ist eine Sammlung von System- und Benutzerdatenbanken mit gemeinsam genutzten Ressourcen. Eine verwaltete Instanz ist wie eine Instanz der SQL Server-Datenbank, die in hohem Maße mit dem lokalen SQL Server kompatibel ist. Eine verwaltete Instanz verfügt über integrierte Sicherungen, Patches und Wiederherstellung und lässt sich einfach von SQL Server migrieren. Es gibt jedoch eine kleine Anzahl von SQL Server-Features, die nicht verfügbar sind, und es gibt keine garantierte genaue Wartungszeit.
Azure Virtual Machine Mit dieser Option können Sie SQL Server in einer virtuellen Maschine in der Azure-Cloud ausführen. Sie haben die volle Kontrolle über die SQL Server-Engine und einen einfachen Migrationspfad. Aber Sie müssen Ihre Backups, Patches und Wiederherstellungen verwalten.
Weitere Informationen finden Sie unter Auswählen Ihres Datenbankmigrationspfads zu Azure und Auswählen der richtigen SQL Server-Option in Azure .
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 dass eine verknüpfte Tabelle einen Primärschlüssel hat, wenn die Tabelle aktualisiert werden kann.
Primär-/Fremdschlüsselbeziehungen prüfen 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 Anlagespalte SSMA migriert keine Tabellen, die die Anlagespalte 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 aktuelle Benutzer, die mit der Datenbank verbunden sind, auch die Datenbank schließen.
Wenn die Datenbank im MDB-Dateiformat vorliegt , entfernen Sie die Sicherheit auf Benutzerebene .
Sichern Sie Ihre Datenbank. Weitere Informationen finden Sie unter Schützen Sie Ihre Daten mit Sicherungs- und Wiederherstellungsprozessen .
Tipp Erwägen Sie die Installation von Microsoft SQL Server Express Edition auf Ihrem Desktop, die bis zu 10 GB unterstützt und eine kostenlose und einfachere Möglichkeit darstellt, Ihre Migration durchzuführen und zu überprüfen. Verwenden Sie beim Verbinden LocalDB als Datenbankinstanz .
Tipp Verwenden Sie nach Möglichkeit eine eigenständige Version von Access. Wenn Sie nur Microsoft 365 verwenden können, verwenden Sie das Access 2010-Datenbankmodul, um Ihre Access-Datenbank bei Verwendung von SSMA zu migrieren. Weitere Informationen finden Sie unter Microsoft Access Database Engine 2010 Redistributable .
Führen Sie SSMA aus
Microsoft stellt den Microsoft SQL Server-Migrationsassistenten (SSMA) bereit, um die Migration zu vereinfachen. SSMA migriert hauptsächlich Tabellen und ausgewählte Abfragen ohne Parameter. Formulare, Berichte, Makros und VBA-Module werden nicht konvertiert. Der SQL Server-Metadaten-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, falls Sie sich entscheiden, in Zukunft weitere Objekte zu übertragen.
Hinweis Der Migrationsprozess kann abhängig von der Größe Ihrer Datenbankobjekte und der zu übertragenden Datenmenge einige Zeit in Anspruch nehmen.
Um eine Datenbank mit SSMA zu migrieren, laden Sie zunächst 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 SSMA nach der Installation auf Ihrem Desktop, vorzugsweise auf dem Computer mit der Access-Datenbankdatei.
Sie können es auch auf einem Computer öffnen, der über das Netzwerk Zugriff auf die Access-Datenbank in einem freigegebenen Ordner hat.
Befolgen Sie die anfänglichen Anweisungen in SSMA, um grundlegende Informationen wie den SQL Server-Speicherort, die Access-Datenbank und die zu migrierenden Objekte, Verbindungsinformationen und die Angabe, ob Sie verknüpfte Tabellen erstellen möchten, 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 Überprüfungstools > Projekteinstellungen > Allgemein auswählen.
Das rowversion-Feld hilft, Datensatzkonflikte zu vermeiden. Access verwendet dieses Zeilenversionsfeld in einer verknüpften SQL Server-Tabelle, um zu bestimmen, wann der Datensatz zuletzt aktualisiert wurde. Wenn Sie einer Abfrage das Feld rowversion hinzufügen, verwendet Access es außerdem, 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 von der ursprünglichen Ü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 Zeilenversion.
Hinweis Vermeiden Sie es, rowversion mit Zeitstempeln zu verwechseln. Obwohl das Schlüsselwort timestamp in SQL Server ein Synonym für rowversion ist, können Sie rowversion nicht verwenden, um einen Dateneintrag mit einem Zeitstempel zu versehen.
Um genaue Datentypen festzulegen, wählen Sie Review Tools > Project Settings > Type Mapping aus. Wenn Sie beispielsweise nur englischen Text speichern, können Sie anstelle des Datentyps nvarchar den Datentyp varchar verwenden.
Objekte umwandeln
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 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 mit Nulllänge zulassen, Spaltenvalidierungsregel, Tabellenvalidierung)
Verwenden Sie als Best Practice den SSMA-Bewertungsbericht, der die Konvertierungsergebnisse anzeigt, einschließlich Fehler, Warnungen, Informationsmeldungen, Zeitschätzungen für die Durchführung der Migration und einzelne Fehlerkorrekturschritte, die Sie ausführen müssen, bevor Sie die Objekte tatsächlich verschieben.
Beim Konvertieren von Datenbankobjekten werden die Objektdefinitionen aus den Access-Metadaten übernommen, in die entsprechende Transact-SQL (T-SQL)-Syntax konvertiert und diese Informationen dann in das Projekt geladen. Anschließend können Sie die SQL Server- oder SQL Azure-Objekte und ihre Eigenschaften mithilfe von SQL Server oder SQL Azure-Metadaten-Explorer anzeigen.
Befolgen Sie zum Konvertieren, Laden und Migrieren von Objekten zu SQL Server diese Anleitung .
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 SQL Server OLE DB- und ODBC-Treiber 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 Features in Azure SQL, die die vorherigen Treiber nicht unterstützen. 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 zu den Tabellen in SQL Server herstellen, die jetzt Ihre Daten hosten. Die direkte Verknüpfung von Access bietet Ihnen auch eine einfachere Möglichkeit, Ihre Daten anzuzeigen, anstatt die komplexeren SQL Server-Verwaltungstools zu verwenden. Abhängig von den Berechtigungen, die von Ihrem SQL Server-Datenbankadministrator eingerichtet wurden, können Sie verknüpfte Daten abfragen und bearbeiten.
Hinweis Wenn Sie beim Verknüpfen mit Ihrer SQL Server-Datenbank während des Verknüpfungsprozesses einen ODBC-DSN erstellen, erstellen Sie entweder denselben DSN auf allen Computern, die die neue Anwendung verwenden, oder verwenden Sie programmgesteuert die in der DSN-Datei gespeicherte Verbindungszeichenfolge.
Weitere Informationen finden Sie unter Verknüpfen mit oder Importieren von Daten aus einer Azure SQL Server-Datenbank und Importieren oder Verknüpfen von Daten in einer SQL Server-Datenbank.
Tipp Vergessen Sie nicht, den Linked Table Manager in Access zu verwenden, um Tabellen bequem zu aktualisieren und neu zu verknüpfen. Weitere Informationen finden Sie unter Verknüpfte Tabellen verwalten .
Testen und überarbeiten
In den folgenden Abschnitten werden allgemeine Probleme beschrieben, auf die Sie während der Migration stoßen können, und wie Sie damit umgehen.
Abfragen
Nur Auswahlabfragen werden konvertiert; andere Abfragen sind dies nicht, einschließlich Auswahlabfragen, 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 das manuelle Konvertieren von Access-spezifischen Funktionen und Datentypen in solche von SQL Server erforderlich machen. Weitere Informationen finden Sie unter Vergleichen von Access SQL mit SQL Server TSQL .
Datentypen
Access und SQL Server haben ähnliche Datentypen, aber beachten Sie die folgenden potenziellen Probleme.
Große Zahl Der Datentyp „Große Zahl" speichert einen nicht monetären, numerischen Wert und ist mit dem Bigint-Datentyp von SQL 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 funktioniert besser mit der 64-Bit-Version von Access. Weitere Informationen finden Sie unter Verwenden des Datentyps „Große Zahl" und Wählen Sie 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 das Sperren von Datensätzen zu vermeiden, stellen Sie sicher, dass das Bitfeld so eingestellt ist, dass es NULL-Werte nicht zulässt. IN SSMA können Sie die Bitspalte auswählen, um die Eigenschaft Nullwerte zulassen auf NEIN festzulegen. Verwenden Sie in TSQL die Anweisungen CREATE TABLE oder ALTER TABLE .
Datum und Uhrzeit Es gibt mehrere Datums- und Uhrzeitüberlegungen:
Wenn der Kompatibilitätsgrad der Datenbank 130 (SQL Server 2016) oder höher ist und eine verknüpfte Tabelle 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 Zugriff auf verknüpfte Tabelle auf SQL-Server-Datenbank gibt #deleted zurück .
Verwenden Sie den Datentyp „Zugriffsdatum/-zeit", um ihn dem Datentyp „datetime" zuzuordnen. Verwenden Sie den erweiterten Datentyp „Zugriff auf Datum/Uhrzeit", um ihn dem Datentyp „ datetime2 " zuzuordnen, der einen größeren Datums- und Zeitbereich hat. Weitere Informationen finden Sie unter Verwenden des erweiterten Datum/Uhrzeit-Datentyps.
Berücksichtigen Sie beim Abfragen von Datumsangaben in SQL Server sowohl die Uhrzeit als auch das Datum. Zum Beispiel:
Bestelldatum Zwischen dem 1.1.19 und dem 31.1.19 sind möglicherweise nicht alle Bestellungen enthalten.
Das Bestelldatum zwischen dem 1.1.19 00:00:00 Uhr und dem 31.1.19 23:59:59 Uhr umfasst alle Bestellungen.
Anhang Der Datentyp Anhang speichert eine Datei in der Access-Datenbank. In SQL Server müssen Sie mehrere Optionen berücksichtigen. Sie können die Dateien aus der Access-Datenbank extrahieren und dann erwägen, Links zu den Dateien in Ihrer SQL Server-Datenbank zu speichern. Alternativ können Sie FILESTREAM, FileTables oder Remote BLOB Store (RBS) verwenden, um Anhänge in der SQL Server-Datenbank gespeichert zu halten.
Hyperlinkzugriffstabellen haben Hyperlinkspalten, die von SQL Server nicht unterstützt werden. Standardmäßig werden diese Spalten in SQL Server in nvarchar(max)-Spalten konvertiert, aber Sie können die Zuordnung anpassen, um einen kleineren Datentyp auszuwählen. In Ihrer Access-Lösung können Sie das Hyperlink-Verhalten 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 Viele-zu-Viele-Beziehung modelliert, sind möglicherweise zusätzliche Entwurfs- und Konvertierungsarbeiten erforderlich.
Weitere Informationen zum Zuordnen von Access- und SQL Server-Datentypen finden Sie unter Datentypen vergleichen .
Hinweis Mehrwertige Felder werden nicht konvertiert und wurden in Access 2010 eingestellt.
Weitere Informationen finden Sie unter Datums- und Uhrzeittypen , String- und Binärtypen und Numerische Typen .
VisualBasic
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 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 kann diese benutzerdefinierten Funktionen nicht ausführen. Möglicherweise müssen Sie diese Funktionen manuell neu entwerfen und sie in gespeicherte Prozeduren auf SQL Server konvertieren.
Leistung optimieren
Die bei weitem wichtigste Möglichkeit, die Leistung Ihres neuen Back-End-SQL-Servers zu optimieren, besteht darin, zu entscheiden, wann lokale oder Remoteabfragen verwendet werden sollen. Wenn Sie Ihre Daten zu SQL Server migrieren, bewegen Sie sich auch von einem Dateiserver zu einem Client-Server-Datenbankmodell der Datenverarbeitung. Befolgen Sie diese allgemeinen Richtlinien:
Führen Sie für den schnellsten Zugriff kleine, schreibgeschützte Abfragen auf dem Client aus.
Führen Sie lange Lese-/Schreibabfragen auf dem Server aus, um die größere Verarbeitungsleistung zu nutzen.
Minimieren Sie den Netzwerkverkehr mit Filtern und Aggregation, um nur die Daten zu übertragen, die Sie benötigen.
Weitere Informationen finden Sie unter Erstellen einer Pass-Through-Abfrage .
Im Folgenden finden Sie zusätzliche, empfohlene Richtlinien.
Logik auf dem Server platzieren Ihre Anwendung kann auch Ansichten, benutzerdefinierte Funktionen, gespeicherte Prozeduren, berechnete Felder und Trigger verwenden, um Anwendungslogik, Geschäftsregeln und -richtlinien, komplexe Abfragen, Datenvalidierung und referenziellen Integritätscode auf dem Server zu zentralisieren und gemeinsam zu nutzen , und nicht auf dem Client. 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.
Ansichten in Formularen und Berichten verwenden Gehen Sie in Access wie folgt vor:
Verwenden Sie für Formulare eine SQL-Ansicht für ein schreibgeschütztes Formular und eine indizierte SQL-Ansicht für ein Lese-/Schreibformular als Datensatzquelle.
Verwenden Sie für Berichte eine SQL-Ansicht als Datensatzquelle. Erstellen Sie jedoch für jeden Bericht eine separate Ansicht, damit Sie einen bestimmten Bericht einfacher aktualisieren können, ohne andere Berichte zu beeinträchtigen.
Minimieren Sie das Laden von Daten in ein Formular oder einen Bericht . Zeigen Sie Daten erst an, wenn der Benutzer danach fragt. Lassen Sie beispielsweise die Eigenschaft recordsource leer, lassen Sie die Benutzer einen Filter in Ihrem Formular auswählen und füllen Sie dann die Eigenschaft recordsource mit Ihrem Filter aus. Oder verwenden Sie die where-Klausel von DoCmd.OpenForm und DoCmd.OpenReport, um die genauen Datensätze anzuzeigen, die der Benutzer benötigt. Erwägen Sie, die Datensatznavigation zu deaktivieren.
Vorsicht bei heterogenen Abfragen Vermeiden Sie die Ausführung einer Abfrage, die eine lokale Access-Tabelle und eine verknüpfte SQL Server-Tabelle kombiniert, was manchmal auch als Hybridabfrage bezeichnet wird. Diese Art von Abfrage erfordert weiterhin, dass Access alle SQL Server-Daten auf den lokalen Computer herunterlädt und dann die Abfrage ausführt. Die Abfrage wird nicht in SQL Server ausgeführt.
Wann sollten lokale Tabellen verwendet werden Ziehen Sie die Verwendung lokaler Tabellen für Daten in Betracht, 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 auf dem Access-Front-End eine bessere Leistung erbringen.
Weitere Informationen finden Sie unter Database Engine Tuning Advisor , Use the Performance Analyzer to optimize an Access database und Optimizing Microsoft Office Access Applications Linked to SQL Server .
Siehe auch
Azure Database-Migrationsleitfaden
Microsoft-Blog zur Datenmigration
Migration, Konvertierung und Upsizing von Microsoft Access zu SQL Server
No comments:
Post a Comment