Bild 1: Beispiel für ein zu migrierendes Datenmodell
Viele Leser dieses Magazins programmieren auch mit Access. Der eine oder andere hat vielleicht sogar eigene Anwendungen oder Anwendungen von Kunden auf Access-Basis, die er gern in Form eines WPF- oder ASP.NET-Projekts umsetzen würde. Das Problem: Der Zugriff auf die Access-Datenbank ist unter .NET nur begrenzt möglich, die tolle Datenzugriffstechnologie Entity Framework beispielsweise unterstützt Access-Datenbanken nicht. Dafür unterstützt es allerdings SQL Server-Datenbanken. Wie gehen wir also vor Wir migrieren die Access-Datenbanken zum SQL Server und bauen dann ein Entity Data Model auf Basis dieser Datenbank. Es geht allerdings auch anders: Sie könnten auch ein paar Routinen in VBA schreiben, die ein Entity Data Model direkt aus Access heraus auf Basis des gewünschten Datenmodells erzeugen. Dieser Artikel zeigt, wie letztere Möglichkeit funktioniert.
Als Beispiel habe ich eine kleine Bestellverwaltung zusammengestellt, welche die wesentlichen Tabellen enthält (siehe Bild 1).
Bild 1: Beispiel für ein zu migrierendes Datenmodell
Ziel ist es, aus diesem Datenmodell und den enthaltenen Daten ein Entity Data Model mit je einer Klasse für jede Tabelle und einer Liste der benötigten DbSet-Auflistungen zu erstellen.
Außerdem wollen wir die Befehle für eine Seed-Methode zusammenstellen, die notwendig ist, um die Daten aus den Access-Tabellen dann beim Initialisieren des Entity Data Models in die zu erstellende Datenbank zu schreiben. Die Grundlagen zur Initialisierung einer Datenbank finden Sie im Artikel Entity Framework: Datenbankinitialisierung.
Was wollen wir also genau tun Wir möchten beispielsweise für die Tabelle tblAnreden, deren Entwurf Sie in Bild 2 sehen, zwei Dinge erzeugen:
Bild 2: Zu migrierende Tabelle
- die Definition einer Klasse und
- die Definition eines DbSet-Objekts.
Die Klassendefinition soll beispielsweise wie folgt aussehen:
Public Class Anrede Public Property AnredeID As System.Int32 Public Property Anrede As System.String End Class
Die Definition des DbSet-Objekts lautet so:
Public Overridable Property Anreden() As DbSet(Of Anrede)
Hier würden wir von einer automatischen Erfassung des Tabellennamens, der Felder und des Primärschlüssels ausgehen und von ein paar Anpassungen, um die Migration einigermaßen tauglich zu gestalten und beispielsweise nicht das Präfix tbl mitzuschleppen. Wir sehen hier, dass die Klasse beispielsweise Anrede heißt. Diese Bezeichnung können wir nur schwer aus dem Tabellennamen extrahieren, also holen wir ihn aus dem Namen des Primärschlüsselfeldes (hier AnredeID), von dem wir lediglich den Zusatz ID entfernen. Die beiden Felder belassen wir im ersten Schritt bei AnredeID und Anrede. Optimaler wäre beispielsweise ID und Name. Ersteres, weil wir in der objektorientierten Programmierung etwa über
Beispieldatenbank
Die Beispieldatenbank enthält die im Beziehungen-Fenster von Access abgebildeten Tabellen und Beziehungen. Diese wollen wir nun, möglichst ohne manuellen Eingriff, in die entsprechenden Entitäten und DbSets umwandeln. Dazu können wir zwei Wege gehen: Entweder wir greifen von einem Visual Studio-Projekt aus auf die Datenbank zu oder wir bauen unsere Routinen direkt in der Access-Datenbank. Mir selbst geht VBA beim Zugriff auf Tabellen, Felder, Beziehungen und so weiter immer noch viel schneller von der Hand als mit VB oder C#. Außerdem wäre der Zugriff, wie er für das Auslesen der Access-Tabellen nötig wäre, eine Technik, die wir prinzipiell unter .NET nicht mehr benötigen – hier wollen wir Datenbanksysteme wie SQL Server oder SQLite nutzen, auf die wir mit dem Entity Framework zugreifen können.
Außerdem dürfte das Programmieren von Routinen, die uns aus dem Access-Datenmodell ein Entity Data Model macht, mit einer Menge Testen und Ändern verbunden sein. Das geht unter Access wesentlich schneller und komfortabler als in Visual Studio. In Access schreiben wir einfach die Prozeduren und klicken auf F5, um diese auszuführen, in Visual Studio müssten wir immer das Projekt neu starten, die Ausführung prüfen, das Projekt wieder beenden, den Code anpassen und das Ganze immer wieder von vorn beginnen. Also entscheiden wir uns in diesem Fall für die ältere, aber pragmatischere Vorgehensweise.
.NET-Projekt zum Testen vorbereiten
Damit wir die gleich unter Access generierten Klassen im .NET-Projekt auf ihre Tauglichkeit prüfen können, legen wir gleich ein neues Projekt des Typs VB|WPF-App mit dem Namen AccessZuEF an. Diesem fügen wir ein neues Objekt des Typs ADO.NET Entity Data Model namens BestellverwaltungContext mit dem Typ Leeres Code First-Modell hinzu. Dies legt automatisch die Klasse BestellverwaltungContext.vb für uns an, der wir dann gleich unsere Liste der DbSet-Elemente hinzufügen können. Der Einfachheit halber packen wir unsere Class-Elemente zum Testen auch erst einmal hier herein.
Zugriff auf die Tabellen, Felder und Beziehungen
Bild 1: Beispiel für ein zu migrierendes Datenmodell
Viele Leser dieses Magazins programmieren auch mit Access. Der eine oder andere hat vielleicht sogar eigene Anwendungen oder Anwendungen von Kunden auf Access-Basis, die er gern in Form eines WPF- oder ASP.NET-Projekts umsetzen würde. Das Problem: Der Zugriff auf die Access-Datenbank ist unter .NET nur begrenzt möglich, die tolle Datenzugriffstechnologie Entity Framework beispielsweise unterstützt Access-Datenbanken nicht. Dafür unterstützt es allerdings SQL Server-Datenbanken. Wie gehen wir also vor Wir migrieren die Access-Datenbanken zum SQL Server und bauen dann ein Entity Data Model auf Basis dieser Datenbank. Es geht allerdings auch anders: Sie könnten auch ein paar Routinen in VBA schreiben, die ein Entity Data Model direkt aus Access heraus auf Basis des gewünschten Datenmodells erzeugen. Dieser Artikel zeigt, wie letztere Möglichkeit funktioniert.
Als Beispiel habe ich eine kleine Bestellverwaltung zusammengestellt, welche die wesentlichen Tabellen enthält (siehe Bild 1).
Bild 1: Beispiel für ein zu migrierendes Datenmodell
Ziel ist es, aus diesem Datenmodell und den enthaltenen Daten ein Entity Data Model mit je einer Klasse für jede Tabelle und einer Liste der benötigten DbSet-Auflistungen zu erstellen.
Außerdem wollen wir die Befehle für eine Seed-Methode zusammenstellen, die notwendig ist, um die Daten aus den Access-Tabellen dann beim Initialisieren des Entity Data Models in die zu erstellende Datenbank zu schreiben. Die Grundlagen zur Initialisierung einer Datenbank finden Sie im Artikel Entity Framework: Datenbankinitialisierung.
Was wollen wir also genau tun Wir möchten beispielsweise für die Tabelle tblAnreden, deren Entwurf Sie in Bild 2 sehen, zwei Dinge erzeugen:
Bild 2: Zu migrierende Tabelle
- die Definition einer Klasse und
- die Definition eines DbSet-Objekts.
Die Klassendefinition soll beispielsweise wie folgt aussehen:
Public Class Anrede
Public Property AnredeID As System.Int32
Public Property Anrede As System.String
End Class
Die Definition des DbSet-Objekts lautet so:
Public Overridable Property Anreden() As DbSet(Of Anrede)
Hier würden wir von einer automatischen Erfassung des Tabellennamens, der Felder und des Primärschlüssels ausgehen und von ein paar Anpassungen, um die Migration einigermaßen tauglich zu gestalten und beispielsweise nicht das Präfix tbl mitzuschleppen. Wir sehen hier, dass die Klasse beispielsweise Anrede heißt. Diese Bezeichnung können wir nur schwer aus dem Tabellennamen extrahieren, also holen wir ihn aus dem Namen des Primärschlüsselfeldes (hier AnredeID), von dem wir lediglich den Zusatz ID entfernen. Die beiden Felder belassen wir im ersten Schritt bei AnredeID und Anrede. Optimaler wäre beispielsweise ID und Name. Ersteres, weil wir in der objektorientierten Programmierung etwa über . auf die Eigenschaften einer Entität zugreifen und Anrede.AnredeID schlicht redundante Daten enthält – Anrede.ID wäre viel schöner. Und Anrede.Anrede ist ebenfalls optimierungsfähig. Für die Deklaration des DbSet-Objekts verwenden wir aktuell den Namen der Tabelle ohne das Präfix tbl und für den Typ der im DbSet enthaltenen Daten verwenden wir wieder den aus dem Primärschlüsselfeld ermittelten Namen, also Anrede. Gerade bei den Bezeichnern für die DbSets und die Entitäten muss man darauf achten, ob sich Plural und Singular unterscheiden. Das ist beispielsweise bei Artikel schwierig (ein Artikel/zwei Artikel), weshalb man, wenn man schon weiß, dass man mal objektorientiert mit dem Datenmodell seiner Datenbank arbeiten möchte, besser gleich eine Bezeichnung wie Produkt/Produkte verwendet. In unserer Beispieldatenbank verwenden wir aber weiter tblArtikel, gerade weil wir auch zeigen wollen, wie Sie solche Probleme durch Umbenennungen lösen können.
Beispieldatenbank
Die Beispieldatenbank enthält die im Beziehungen-Fenster von Access abgebildeten Tabellen und Beziehungen. Diese wollen wir nun, möglichst ohne manuellen Eingriff, in die entsprechenden Entitäten und DbSets umwandeln. Dazu können wir zwei Wege gehen: Entweder wir greifen von einem Visual Studio-Projekt aus auf die Datenbank zu oder wir bauen unsere Routinen direkt in der Access-Datenbank. Mir selbst geht VBA beim Zugriff auf Tabellen, Felder, Beziehungen und so weiter immer noch viel schneller von der Hand als mit VB oder C#. Außerdem wäre der Zugriff, wie er für das Auslesen der Access-Tabellen nötig wäre, eine Technik, die wir prinzipiell unter .NET nicht mehr benötigen – hier wollen wir Datenbanksysteme wie SQL Server oder SQLite nutzen, auf die wir mit dem Entity Framework zugreifen können.
Außerdem dürfte das Programmieren von Routinen, die uns aus dem Access-Datenmodell ein Entity Data Model macht, mit einer Menge Testen und Ändern verbunden sein. Das geht unter Access wesentlich schneller und komfortabler als in Visual Studio. In Access schreiben wir einfach die Prozeduren und klicken auf F5, um diese auszuführen, in Visual Studio müssten wir immer das Projekt neu starten, die Ausführung prüfen, das Projekt wieder beenden, den Code anpassen und das Ganze immer wieder von vorn beginnen. Also entscheiden wir uns in diesem Fall für die ältere, aber pragmatischere Vorgehensweise.
.NET-Projekt zum Testen vorbereiten
Damit wir die gleich unter Access generierten Klassen im .NET-Projekt auf ihre Tauglichkeit prüfen können, legen wir gleich ein neues Projekt des Typs VB|WPF-App mit dem Namen AccessZuEF an. Diesem fügen wir ein neues Objekt des Typs ADO.NET Entity Data Model namens BestellverwaltungContext mit dem Typ Leeres Code First-Modell hinzu. Dies legt automatisch die Klasse BestellverwaltungContext.vb für uns an, der wir dann gleich unsere Liste der DbSet-Elemente hinzufügen können. Der Einfachheit halber packen wir unsere Class-Elemente zum Testen auch erst einmal hier herein.
Zugriff auf die Tabellen, Felder und Beziehungen
Access, SQL und Cloud Automation
Unser exklusives Angebot für Dich!
VB-Entwickler
12,50 €
im Monat*
(Gilt für den Abschluss eines Jahres-Abonnements.)
Hier geht’s weiter →
Die ersten 4 Wochen kostenlos testen – voller Zugriff auf alle
Artikel, vollständigen Code und Beispieldatenbanken. Kein Risiko:
Wenn es nicht passt, kündigst Du einfach innerhalb der ersten vier Wochen.
Kostenlos & unverbindlichOder hast Du eine konkrete Frage zu Deiner eigenen Access-Anwendung?
Bild 1: Beispiel für ein zu migrierendes Datenmodell
Viele Leser dieses Magazins programmieren auch mit Access. Der eine oder andere hat vielleicht sogar eigene Anwendungen oder Anwendungen von Kunden auf Access-Basis, die er gern in Form eines WPF- oder ASP.NET-Projekts umsetzen würde. Das Problem: Der Zugriff auf die Access-Datenbank ist unter .NET nur begrenzt möglich, die tolle Datenzugriffstechnologie Entity Framework beispielsweise unterstützt Access-Datenbanken nicht. Dafür unterstützt es allerdings SQL Server-Datenbanken. Wie gehen wir also vor Wir migrieren die Access-Datenbanken zum SQL Server und bauen dann ein Entity Data Model auf Basis dieser Datenbank. Es geht allerdings auch anders: Sie könnten auch ein paar Routinen in VBA schreiben, die ein Entity Data Model direkt aus Access heraus auf Basis des gewünschten Datenmodells erzeugen. Dieser Artikel zeigt, wie letztere Möglichkeit funktioniert.
Als Beispiel habe ich eine kleine Bestellverwaltung zusammengestellt, welche die wesentlichen Tabellen enthält (siehe Bild 1).
Bild 1: Beispiel für ein zu migrierendes Datenmodell
Ziel ist es, aus diesem Datenmodell und den enthaltenen Daten ein Entity Data Model mit je einer Klasse für jede Tabelle und einer Liste der benötigten DbSet-Auflistungen zu erstellen.
Außerdem wollen wir die Befehle für eine Seed-Methode zusammenstellen, die notwendig ist, um die Daten aus den Access-Tabellen dann beim Initialisieren des Entity Data Models in die zu erstellende Datenbank zu schreiben. Die Grundlagen zur Initialisierung einer Datenbank finden Sie im Artikel Entity Framework: Datenbankinitialisierung.
Was wollen wir also genau tun Wir möchten beispielsweise für die Tabelle tblAnreden, deren Entwurf Sie in Bild 2 sehen, zwei Dinge erzeugen:
Bild 2: Zu migrierende Tabelle
- die Definition einer Klasse und
- die Definition eines DbSet-Objekts.
Die Klassendefinition soll beispielsweise wie folgt aussehen:
Public Class Anrede Public Property AnredeID As System.Int32 Public Property Anrede As System.String End Class
Die Definition des DbSet-Objekts lautet so:
Public Overridable Property Anreden() As DbSet(Of Anrede)
Hier würden wir von einer automatischen Erfassung des Tabellennamens, der Felder und des Primärschlüssels ausgehen und von ein paar Anpassungen, um die Migration einigermaßen tauglich zu gestalten und beispielsweise nicht das Präfix tbl mitzuschleppen. Wir sehen hier, dass die Klasse beispielsweise Anrede heißt. Diese Bezeichnung können wir nur schwer aus dem Tabellennamen extrahieren, also holen wir ihn aus dem Namen des Primärschlüsselfeldes (hier AnredeID), von dem wir lediglich den Zusatz ID entfernen. Die beiden Felder belassen wir im ersten Schritt bei AnredeID und Anrede. Optimaler wäre beispielsweise ID und Name. Ersteres, weil wir in der objektorientierten Programmierung etwa über
Beispieldatenbank
Die Beispieldatenbank enthält die im Beziehungen-Fenster von Access abgebildeten Tabellen und Beziehungen. Diese wollen wir nun, möglichst ohne manuellen Eingriff, in die entsprechenden Entitäten und DbSets umwandeln. Dazu können wir zwei Wege gehen: Entweder wir greifen von einem Visual Studio-Projekt aus auf die Datenbank zu oder wir bauen unsere Routinen direkt in der Access-Datenbank. Mir selbst geht VBA beim Zugriff auf Tabellen, Felder, Beziehungen und so weiter immer noch viel schneller von der Hand als mit VB oder C#. Außerdem wäre der Zugriff, wie er für das Auslesen der Access-Tabellen nötig wäre, eine Technik, die wir prinzipiell unter .NET nicht mehr benötigen – hier wollen wir Datenbanksysteme wie SQL Server oder SQLite nutzen, auf die wir mit dem Entity Framework zugreifen können.
Außerdem dürfte das Programmieren von Routinen, die uns aus dem Access-Datenmodell ein Entity Data Model macht, mit einer Menge Testen und Ändern verbunden sein. Das geht unter Access wesentlich schneller und komfortabler als in Visual Studio. In Access schreiben wir einfach die Prozeduren und klicken auf F5, um diese auszuführen, in Visual Studio müssten wir immer das Projekt neu starten, die Ausführung prüfen, das Projekt wieder beenden, den Code anpassen und das Ganze immer wieder von vorn beginnen. Also entscheiden wir uns in diesem Fall für die ältere, aber pragmatischere Vorgehensweise.
.NET-Projekt zum Testen vorbereiten
Damit wir die gleich unter Access generierten Klassen im .NET-Projekt auf ihre Tauglichkeit prüfen können, legen wir gleich ein neues Projekt des Typs VB|WPF-App mit dem Namen AccessZuEF an. Diesem fügen wir ein neues Objekt des Typs ADO.NET Entity Data Model namens BestellverwaltungContext mit dem Typ Leeres Code First-Modell hinzu. Dies legt automatisch die Klasse BestellverwaltungContext.vb für uns an, der wir dann gleich unsere Liste der DbSet-Elemente hinzufügen können. Der Einfachheit halber packen wir unsere Class-Elemente zum Testen auch erst einmal hier herein.
Zugriff auf die Tabellen, Felder und Beziehungen
Unser exklusives Angebot für Dich!
(Gilt für den Abschluss eines Jahres-Abonnements.)
Hier geht’s weiter →Die ersten 4 Wochen kostenlos testen – voller Zugriff auf alle Artikel, vollständigen Code und Beispieldatenbanken. Kein Risiko: Wenn es nicht passt, kündigst Du einfach innerhalb der ersten vier Wochen.
Vielleicht stellt Deine Anwendung Dich vor eine Herausforderung, zu der Du bisher keine Lösung findest. Schlechte Performance, kein ausreichender Zugriffsschutz, Du bist unsicher über Dein Datenmodell oder Dein Code liefert unerklärliche Fehler?
In unserem kostenlosen Access-Audit schaut sich André Minhorst persönlich gemeinsam mit Dir Deine Lösung per Zoom an – und zeigt Dir, wo Datenmodell, VBA-Code, Ergonomie und Sicherheit Optimierungspotenzial bieten.
Jetzt kostenloses Access-Audit anfordern →