Access -> SQL-Server: Tabellen unter der Haube austauschen

[Enomine]

Sehr geehrte Damen und Herren,

##### Situation #####
wir nutzen Microsoft Access mit Frontend und Backend für eine interne Verwaltungssoftware (VS). Die Ladezeiten der VS sind sehr langsam, wir nehmen an wegen ineffizienten Datenbankzugriffen. Deswegen soll die Datenbank umgestellt werden auf Microsoft SQL-Server. Ich bin ein Masterstudent und aus Sicht der Firma "extern eingekauft" und habe keine Erfahrung mit Microsoft Access, vollziehe learning by doing.

##### SMAA #####
Wir wissen, dass ein Migrationstool dafür existiert, sehen aufgrund der Vorbedingungen an die DB aber derzeit keine Möglichkeit das Tool SMAA anzuwenden. Außerdem möchten wir die DB grundlegend überdenken und normalisieren. Statt SMAA haben wir uns überlegt die Datenbank händisch in SQL-Server nachzubilden und diese neu im Access Frontend zu verlinken.

##### Grundproblem #####
Wir möchten alle, also 20-40 Tabellen in SQL-Server abbilden und im Access Frontend statt der bisherigen benutzen. "dbo_Projekte" haben wir probeweise über Externe Daten -> ODBC-Datenbank hinzugefügt. Diese soll "Projekte" ersetzen. (Bild 1)



Über Datenbanktools -> Objektabhängigkeiten sind wir der Meinung alle Vorkommnisse der Tabelle herausfinden zu können. Wir denken auf jedes Formular doppelklicken zu müssen, in dem Eigenschaftenblatt unter dem Dropdownfeld "Formular" auszuwählen und dann bei Datensatzquelle mit rechtsklick auf die "..." mithilfe der Zoom-Funktion die Tabelle beim SQL-Befehl hinter "FROM" umbenennen müssen von "Projekte" auf "dbo_Projekte". (Bild 2)



##### Frage #####
Dies erscheint sehr mühsehlig und Fehleranfällig.
Was ist Ihrer Meinung nach der beste und sicherste Weg, um die Migration durchzuführen?
Ist es beispielsweise möglich die Tabelle / Datenbank direkt unter der Haube zu ersetzen ohne im "Quelltext" Änderungen machen zu müssen? Also sodass die Tabelle "Projekte" auf den SQL-Server zugreift anstatt auf die Access-Backend Datei? (Bild 3)



Dankeschön


Michael

[PhilS]

Sehr geehrte Damen und Herren,

Üblicherweise sind wir hier weniger förmlich.

##### Situation #####
wir nutzen Microsoft Access mit Frontend und Backend für eine interne Verwaltungssoftware (VS). Die Ladezeiten der VS sind sehr langsam, wir nehmen an wegen ineffizienten Datenbankzugriffen. Deswegen soll die Datenbank umgestellt werden auf Microsoft SQL-Server.

Wenn die Datenbankzugriffen in eurer Anwendung ineffizient sind, dann wird eine Umstellung auf SQL Server, ohne die ineffizienten Datenbankzugriffen zu optimieren, euer Performanceproblem schlimmer machen anstatt besser.

##### Frage #####
Was ist Ihrer Meinung nach der beste und sicherste Weg, um die Migration durchzuführen?
Ist es beispielsweise möglich die Tabelle / Datenbank direkt unter der Haube zu ersetzen ohne im "Quelltext" Änderungen machen zu müssen? Also sodass die Tabelle "Projekte" auf den SQL-Server zugreift anstatt auf die Access-Backend Datei? (Bild 3)

Ja. Das hier geschilderte Problem mit dem Tabellennamen lässt sich einfach lösen, indem ihr die eingebundene Access-Tabelle aus der Anwendung entfernt und die SQL Server Tabelle unter demselben Namen einbindet. Damit ist keinerlei Änderung an den Abfragen erforderlich.

Ob dieses Vorgehen den Namen "Migration" verdient, sei dahingestellt.
1. Bin ich skeptisch, ob eure Anwendung damit sofort fehlerfrei funktionieren wird. Es sind evtl. einige Anpassungen an der Anwendungslogik notwendig, um diese überhaupt mit SQL Server lauffähig zu machen.
2. Wie oben angedeutet, wirken sich ineffiziente Datenbankzugriffe mit einem SQL Server Backend noch deutlicher aus, als mit einem Access-Backend. Wenn die Performance der Anwendung bereits jetzt ein Problem ist, ist sie nach einer solchen "Migration" wegen inakzeptabler Performance evtl. komplett unbenutzbar.

[Enomine]

Hallo Phil,

danke für deine Hilfe.
Die Firma hat diese Arbeit als Masterarbeit angeboten, da die Firma die Idee hatte, dass die Langsamkeit des Tools an Access liegen würde (UND an den ineffizienten Datenbankzugriffen). Die Firma ging davon aus, dass der Umstieg auf SQL-Server einen kleinen Geschwindigkeitsschub geben würde (UND zusätzlich die Datenbankzugriffe optimiert werden müssen).

Gibt es eine Möglichkeit in Access herauszufinden welche DB-Zugriffe wie lange dauern (millisekunden), sodass ich evtl. mit einer zeitlichen Analyse die größten Flaschenhälse herausfinden kann?

Insgesamt ist steht Zeit bis Ende April zur Verfügung bei ca. 450 Stunden.

Dankeschön

Michael

[ebs17]

DB-Zugriffe meint doch Zugriffe auf die Tabellen des Backends, also Abfragen.
Abfragen kommen vor als Datenherkunft zu Formularen, Berichten, Kombinationsfeldern, Listenfeldern sowie in Recordsets und als Domänenaggregatfunktionen. Also müsstest Du analysieren, wo so etwas vorkommt, und daran kannst Du dann fühlen wie auch messen, wo es länger dauert.

Abfragen können so oder so formuliert sein. Performancerelevant sind eben eine gute oder ungünstige Abfrageformulierung, sehr wesentlich dann auch eine Indexnutzung. Literatur dazu: Performance in Abfragen von Michael Zimmermann.

Auch interessant, aber in der Wertigkeit deutlich niedriger anzusetzen: Performance in VBA+Formularen von Josef Pötzl

dass die Langsamkeit des Tools an Access liegen würde

Man sollte sicher besser formulieren, Langsamkeit liegt am Umgang mit Access, also an der Entwicklerleistung, zzgl. vorhandener nennenswerter Datenmengen.

Echten Performancezugewinn über den SQL Server gewinnt man, wenn man auch die wesentlichen Abfragen in diesem ausführt. Da ist also etwas mehr zu tun als nur die Tabellen in den SQL Server zu verschieben. Etwas zum Lesen: Access und SQL Server

DB grundlegend überdenken und normalisieren

Das sollte in jedem Fall ganz am Anfang in richtiger Qualität erfolgen. Ohne eine funktionale Datenmodellierung hat man mit jedem DBMS ein Problem, das sich dann auch über Umständlichkeiten in Langsamkeiten auswachsen wird.

[datekk]

Wie PhilS schon geschrieben hat, ist es das einfachste, wenn die eingebundenen SQL Tabellen den gleichen Namen haben. Es ist notwendig, das dbo. vor den Tabellennamen zu entfernen. Das ist kein Problem, das kann man einfach abändern. Danach läuft die Anwendung eigentlich schon wie vorher.

Ich habe anfangs auch meine Access Datenbank mit dem SMMA Tool auf SQL umgestellt. Durch das Tool konnte ich einiges Lernen, z.B. das es manchmal wichtig ist, eine Timestamp Spalte in den Tabellen anzulegen, damit das Problem des doppelten Datenzugriffs vermieden wird welches auftaucht, wenn Daten in einem Formular angezeigt werden.

Es ist auch ohne dieses Tool problemlos möglich, die Tabellen händisch anzulegen. Ihr müsst nur darauf achten, dass sich manche Datentypen im SQL Server von denen in einer Access Tabelle unterscheiden, bzw. dort anders heißen... Beispiel kurzer Text -> nvarchar(255), langer Text -> nvarchar(max), long integer -> int, währung -> currency... Schau mal hier: https://www.berndjungbluth.de/2007/11/12/access-und-sql-server-datentypen/

Die Primärschlüsselfelder sind INT - Felder, müssen als Schlüsselfeld markiert und zusätzlich in den Spalteneigenschaften (Sql Management Studio) Bereich Identitätsspezifikationen -> (ist Identity) -> auf 'Ja' gestellt werden.

Weiterhin können Probleme mit Datumsfeldern auftreten, da SQL Server mit den Datentype DateTime und nicht mit Date arbeiten.

Tabellennamen sollten grundsätzlich keine Leerzeichen enthalten. Weder in Access, noch in SQL. Vermeide auch "_" oder "-" Zeichen. Versuche deine Tabellennamen als ein Wort darzustellen: Beispiel: gelegterUmsatz, KalkulationDirektVKSummen, KostenkomponenteBaaN2...

Access arbeitet grundsätzlich recht langsam, gerade wenn viele Tabellen vorhanden sind, welche eingebunden werden müssen... Ich habe eine große Access Anwendung mit über 30 Tabellen auf SQL Server umgestellt. Zuerst in der geschilderten Variante, dass ich die Tabellen eingebunden habe... Bin dann aber davon weg und binde keine einzige Tabelle mehr ein und arbeite nur noch mit Recordsets.... also ich rufe nur die Daten vom SQL Server ab, welche ich tatsächlich benötige. Dies hat aber weitreichende Eingriffe in der Programmierung der Formulare und Berichte zur Folge, weil kein Formular mehr an eine Tabelle gebunden ist... Das läuft wesentlich schneller, als die Nutzung von verbundenen Tabellen. Wenn Euch das interessiert, lest Euch mal in das Thema ADO-DB Zugriff ein.