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

Hallo!

Zunächst kann man ohne Kenntnis des Ausgangssystems, Nutzeranzahl etc. nichts dazu sagen, ob eine Konvertierung auf SQL Server notwendig ist und wie aufwändig sie sein wird. Auch nicht, ob SSMA sinnvoll ist. Wenn die Struktur, Datentypen etc. des Access-Backends
nicht schwer daneben sind, dann im Normalfall schon. Aber natürlich geht's auch mit dem Neuerstellen der Tabellen und Beziehungen zu Fuß.

Vom bloßen Wechsel des Backends von Access auf SQL Server sollte man sich übrigens keine Performancewunder erwarten. Das hängt davon ab, wie sehr Abfragen, Codes, Datenherkünfte usw. auf Access "fixiert" waren bzw. wie performanceschwach sie formuliert waren.
Das wird dann mit dem Server nicht unbedingt automatisch besser. In manchen Fällen ist die Performance nachher sogar schlechter. Das sollte man möglichst schon vorher abklären und ggf. im Rahmen der Konvertierung an den SQL Server anpassen.

Was die Namen betrifft, so lässt man i.d.R. den Schemanamen "dbo_" als Vorsilbe bei der eingebundenen Tabelle nicht stehen, sondern entfernt ihn. Dann könnte sich das Problem mit "Projekte" reduzieren.

Wenn man wirklich Tabellennamen ändern muss, dann empfiehlt sich die Verwendung eines universellen Suchen/Ersetzen-Tools wie

Find and Replace, denn die Tabellennamen können in allen möglichen Eigenschaften, Ausdrücken, VBA-Codes und Objekten verwendet worden sein.

Hallo,

Im Zoom-Fenster deiner Abfrage kann man erst die Feldliste sehen, danach einen * vor FROM. Das bedeutet, dass nach der Feldliste
alle Felder aller Tabellen angezeigt werden, auch die, die schon in der Feldliste stehen. Ich bezweifle, dass das gewollt ist und in jedem Fall kann sowas Performance-Probleme erzeugen. Man sollte jedes Feld, das
die Abfrage liefern soll, einzeln per Feldname angeben.

Des Weiteren werden alle Tabellen per Outer Join verknüpft. Ist das notwendig? Falls nicht, gäbe es auch hier durch Umstellung auf Inner Join Potential zur Optimierung.

Als nächstes würde ich prüfen, ob alle Felder, die im Join vorkommen, einen Index haben, und falls nicht, anlegen.

Zum Thema SSMA (SQL Server Migration Assisstant)

Ich würde ihn auf jeden Fall einmal über die DB laufen lassen, weil der Report nützliche Informationen über die Machbarkeit der Migration liefert, z.B. ob jede Tabelle einen Primärschlüssel enthält. Sollte es tatsächlich zur Migration kommen, würde er dir
auch beim Verknüpfen der Tabellen helfen, nämlich die lokalen Tabellen umbenennen und die verknüpften mit Original-Namen einbinden. Das dbo_-Problem gäbe es dann nicht.

Ein weiteres hilfreiches Tool ist der
Total Access Analyzer (nicht kostenlos, aber es gibt eine Test-Version), der die Anwendung analysiert und viele hilfreiche Tipps gibt.

Gruss - Peter

Ich habe eine für mich gangbare Lösung gefunden:

Der SQL Server Migration Assistant for Access 8.8.0 weist bei der Uebername von Access-Tabellen in eine SQL-Server DB
Datumfeldern den Datentyp "datetime2" zu. Werden die SQL Server Tabellen in ein Access FE eingebunden ist der "datetime2" Datentyp für Datumfelder in Access zu lang und Access weist dem Feld
automatisch den Datentyp "Text kurz" zu.

Beim Ausprobieren merkte ich dass der SQL Server Datentyp "datetime" (ohne die 2) in Access korrekt in ein Datumformat umgesetzt wird das mir in den Formularen und auf den Berichten das Datum wie gewünscht anzeigt.

Der Rest war dann, bei knapp 100 Tabellen, nur noch Fleissarbeit. In Access darf dann aber nicht vergessen werden die Links der eingebundenen Tabellen zu aktualisieren.

Die Views waren etwas aufwendiger da das Aktualisieren mit dem SSMS 17.9 und dem dbForge Studio Express 5.8.107 nicht funktionierte.

View im Design-Modus öffnen, alle Datum-Felder löschen, View speichern und schliessen.

View im Design-Modus öffnen, alle Datum-Felder wieder einfügen, View speichern und schliessen.In Access die Links der eingebundenen Views aktualisieren.

Ich hoffe das hilft irgendwann jemandem.

Herzliche Grüsse

Reiner

Hallo!

Eine Access-DB in die "Access-Services"-DB zu verlinken wird nicht funktionieren. Welchen Feature-Zuwachs erwartet du vom Verlinken eine File-DB in einem aktiven DBMS?

Umgekehrt funktioniert es schon. Du kannst in einem accdb-Client die Tabellen aus dem SQL-Server verlinken, der für die Access-Services verwendet wird. (Bei Office 365 ist das ein Azure SQL-Server.) Dann kannst du Grundfunktionalitäten über die Access Services
im Sharepoint nutzen und für spezielle Anforderungen VBA in einem Access-Client verwenden.

mfg

Josef

Hallo, Kyle!

Ich wiederhole meinen Hinweis, mit dem ich deinem Kollegen Diego_B vor 2 Wochen hier auf den gleichen Fehllink antwortete:

*****************

Der Download, den du da verlinkt hast, ist eine reine SQL Server-Datenbank, nämlich die uralte Portierung der bloßen ursprünglichen Access-Nordwind-Tabellen auf SQL Server 2000. Dieser Download ist nicht die Access-Beispiel-Datei mit Oberfläche etc., die
die Leute hier suchen.

*****************