![\"Beispiel](\"..\/fileadmin\/_temp_\/2018_05\/pic_148_001.png\")
<\/p>\n<\/p>\n
Bild 1: Beispiel für ein zu migrierendes Datenmodell<\/span><\/b><\/p>\n 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.<\/b><\/p>\n Als Beispiel habe ich eine kleine Bestellverwaltung zusammengestellt, welche die wesentlichen Tabellen enthält (siehe Bild 1).<\/p>\n Bild 1: Beispiel für ein zu migrierendes Datenmodell<\/span><\/b><\/p>\n 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<\/b>-Auflistungen zu erstellen.<\/p>\n Außerdem wollen wir die Befehle für eine Seed<\/b>-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<\/b>.<\/p>\n Was wollen wir also genau tun Wir möchten beispielsweise für die Tabelle tblAnreden<\/b>, deren Entwurf Sie in Bild 2 sehen, zwei Dinge erzeugen:<\/p>\n Bild 2: Zu migrierende Tabelle<\/span><\/b><\/p>\n Die Klassendefinition soll beispielsweise wie folgt aussehen:<\/p>\n Die Definition des DbSet<\/b>-Objekts lautet so:<\/p>\n 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 <\/b>mitzuschleppen. Wir sehen hier, dass die Klasse beispielsweise Anrede <\/b>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<\/b>), von dem wir lediglich den Zusatz ID <\/b>entfernen. Die beiden Felder belassen wir im ersten Schritt bei AnredeID <\/b>und Anrede<\/b>. Optimaler wäre beispielsweise ID <\/b>und Name<\/b>. Ersteres, weil wir in der objektorientierten Programmierung etwa über 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.<\/p>\n 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<\/b>, 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.<\/p>\n 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 <\/b>mit dem Namen AccessZuEF <\/b>an. Diesem fügen wir ein neues Objekt des Typs ADO.NET Entity Data Model <\/b>namens BestellverwaltungContext <\/b>mit dem Typ Leeres Code First-Modell <\/b>hinzu. Dies legt automatisch die Klasse BestellverwaltungContext.vb <\/b>für uns an, der wir dann gleich unsere Liste der DbSet<\/b>-Elemente hinzufügen können. Der Einfachheit halber packen wir unsere Class<\/b>-Elemente zum Testen auch erst einmal hier herein.<\/p>\n Den Zugriff auf die für uns interessanten Elemente gestalten wir mit der DAO-Bibliothek und VBA. Wir arbeiten uns nun Schritt für Schritt an die Umwandlung des Datenmodells und der enthaltenen Daten an die entsprechenden .NET-Klassen heran. Zuerst sehen wir uns ein paar Hilfsfunktionen an, die uns auf dem Weg behilflich sind.<\/p>\n Unter dem Link https:\/\/support.microsoft.com\/de-de\/help\/320435\/info-oledbtype-enumeration-vs-microsoft-access-data-types <\/b>finden wir eine Liste der Access-Datentypen und der entsprechenden Datentypen unter .NET. Daraus bauen wir uns eine kleine Funktion, die den Access-Datentyp als Parameter erwartet und den .NET-Datentyp als Ergebnis zurückliefert. Diese Funktion sieht wie folgt aus:<\/p>\n Die Funktion erwartet drei Parameter, von denen nur der erste Parameter Daten an die Funktion schickt – die übrigen beiden liefern die Rückgabewerte. intDataType <\/b>erwartet die Konstante beziehungsweise den entsprechenden Zahlenwert, den wir aus der Eigenschaft Type <\/b>eines Field<\/b>-Elements erhalten. strDatatype <\/b>liefert den .NET-Datentyp als String zurück. Manche Datentypen werden in .NET als Byte-Array gestaltet. Wenn der Datentyp ein Array erfordert, markieren wir den dritten Parameter bolArray <\/b>als True<\/b>. Es kann auch sein, dass der Datentyp nicht vorhanden ist, was schlicht daran liegt, dass er in dieser Funktion nicht berücksichtigt wird – in diesem Fall kommt der eigentliche Rückgabewert der Funktion zum Einsatz, der den Datentyp Boolean <\/b>hat.<\/p>\n Die Funktion stellt die Variable bolDatatype<\/b>, die festlegt, ob die Funktion einen passenden Datentyp in .NET gefunden hat, standardmäßig auf True <\/b>ein. Diese wird erst auf False <\/b>eingestellt, wenn der Datentyp in der folgenden Select Case<\/b>-Bedingung nicht gefunden wurde. Die Variable bolArray <\/b>wird zuerst auf False <\/b>eingestellt und erhält erst den Wert True<\/b>, wenn der Datentyp ein Array benötigt. Das ist in diesem Fall nötig, da bolArray <\/b>ja auch in der aufrufenden Prozedur verwendet wird und gegebenenfalls vom vorherigen Aufruf noch den Wert True <\/b>enthält. Davon ab vergleicht die Select Case<\/b>-Bedingung den mit intDatatype <\/b>übergebenen Wert mit Konstanten wie dbText<\/b>, dbMemo<\/b>, dbByte <\/b>und so weiter und trägt, wenn sie einen passenen Eintrag gefunden hat, den entsprechenden .NET-Datentyp in die Variable strDatatype <\/b>ein. Am Ende wird schließlich der Wert von bolDatatype <\/b>noch als Rückgabewert der Funktion festgelegt.<\/p>\n Wir gehen davon aus, dass die Primärschlüsselfelder der Tabellen mit einer Bezeichnung versehen sind, die aus dem Singular der Bezeichnung besteht, die sich im Tabellennamen befindet, und der angehängten Zeichenkette ID<\/b> – bei tblAnreden <\/b>also etwa AnredeID<\/b> (das ist zumindest die Konvention, die ich seit 20 Jahren in Magazin Access im Unternehmen <\/b>und in all meinen anderen Veröffentlichungen über Access verwende). Um den Namen herauszubekommen, müssen wir nun allerdings noch zuverlässig bestimmen können, welches Feld das Primärschlüsselfeld ist. Wir gehen an dieser Stelle davon aus, dass jede Tabelle auch nur einen aus einem Feld bestehenden Primärschlüssel verwendet.<\/p>\n Die folgende Funktion namens GetPrimaryKeys <\/b>ermittelt dennoch die Namen aller Primärschlüsselfelder einer Tabelle. Dazu erhält sie mit strTable <\/b>den Tabellennamen als Parameter sowie strPKs <\/b>als Rückgabeparameter. Die Funktion lädt ein TableDef<\/b>-Objekt auf Basis des Namens der Tabelle und durchläuft dann alle Index<\/b>-Elemente dieser Tabelle in einer For Each<\/b>-Schleife. Wenn es sich bei dem Index um einen Primärschlüssel handelt (Primary = True<\/b>), durchläuft die Funktion alle Felder des Indexes und fügt die Namen der Felder in der Variablen strPKTemp <\/b>durch Semikola getrennt aneinander. Das Ergebnis wird mit dem Parameter strPKs <\/b>zurückgeschickt. Der Rückgabewert der Funktion GetPrimaryKeys <\/b>wird mit dem Wert True <\/b>gefüllt, wenn es mindestens ein Primärschlüsselfeld gibt.<\/p>\n Die folgende Funktion GetPrimaryKey <\/b>unterscheidet sich im Namen nur durch den Singular gegenüber dem Plural von der Funktion GetPrimaryKey<\/b>. Was macht diese Funktion Sie ruft in erster Linie die zuvor beschriebene Funktion GetPrimaryKeys <\/b>auf und prüft, ob die mit dem Parameter strTable <\/b>übergebene Tabelle nur um einen oder mehrere Primärschlüssel enthält. Falls es mehrere sind, wird mit strPK <\/b>eine leere Zeichenkette und mit dem Rückgabewert der Wert False <\/b>zurückgegeben. Falls es sich um ein einziges Primärschlüsselfeld handelt, wird mit strPK<\/b> der Name des Primärschlüsselfeldes sowie mit dem Rückgabewert der Wert True <\/b>zurückgeliefert:<\/p>\n In der aufrufenden Prozedur, die wir uns gleich im Anschluss ansehen, können wir dann aufgrund der Rückgabewerte entweder die Definition der Klasse und der DbSet<\/b>-Anweisung zusammenstellen oder eine Meldung ausgeben, dass die Bedingungen für das Erstellen der Elemente wegen keinem Primärschlüsselfeld oder mehr als einem Primärschlüsselfeld nicht gegeben sind.<\/p>\n Die folgende Prozedur erledigt den eigentlichen Teil der Arbeit: Sie nutzt die Ergebnisse der zuvor beschriebenen Funktionen und weitere Daten, um die Klassendefinitionen und die DbSet<\/b>-Deklarationen zusammenzustellen. Im ersten Schritt wollen wir diese noch mit Debug.Print <\/b>im Direktbereich ausgeben. Später werden wir direkt entsprechende Dateien daraus erzeugen, die Sie nur noch aus dem Windows-Explorer in den Projektmappen-Explorer des Ziel-Projekts in Visual Studio ziehen. Die Prozedur heißt EDMErstellen <\/b>und durchläuft nach dem Deklarationsteil zunächst einmal alle TableDef<\/b>-Elemente, also alle Tabellendefinitionen, der mit CurrentDb <\/b>referenzierten Datenbank – also der aktuell geöffneten Datenbank:<\/p>\n Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span><\/p>\n![\"Zu](\"..\/fileadmin\/_temp_\/2018_05\/pic_148_002.png\")
<\/p>\n\n
Public Class<\/span> Anrede\r\n Public <\/span>Property AnredeID As <\/span>System.Int32\r\n Public <\/span>Property Anrede As <\/span>System.String\r\nEnd Class<\/span><\/pre>\nPublic <\/span>Overridable Property Anreden() As <\/span>DbSet(Of Anrede)<\/pre>\nBeispieldatenbank<\/h2>\n
.NET-Projekt zum Testen vorbereiten<\/h2>\n
Zugriff auf die Tabellen, Felder und Beziehungen<\/h2>\n
Datentypen umwandeln<\/h2>\n
Public Function <\/span>DataTypeNET(intDatatype As <\/span>DataTypeEnum, strDatatype As String<\/span>, bolArray As Boolean<\/span>) As Boolean<\/span>\r\n Dim <\/span>bolDatatype As Boolean<\/span>\r\n bolDatatype = True<\/span>\r\n bolArray = False<\/span>\r\n Select Case intDatatype\r\n Case <\/span>dbText: strDatatype = \"System.String\"\r\n Case <\/span>dbMemo: strDatatype = \"System.String\"\r\n Case <\/span>dbByte: strDatatype = \"System.Byte\"\r\n Case <\/span>dbBoolean: strDatatype = \"System.Boolean\"\r\n Case <\/span>dbDate: strDatatype = \"System.DateTime\"\r\n Case <\/span>dbCurrency: strDatatype = \"System.Decimal\"\r\n Case <\/span>dbDecimal: strDatatype = \"System.Decimal\"\r\n Case <\/span>dbDouble: strDatatype = \"System.Double\"\r\n Case <\/span>dbGUID: strDatatype = \"System.Guid\"\r\n Case <\/span>dbLong: strDatatype = \"System.Int32\"\r\n Case <\/span>dbLongBinary\r\n strDatatype = \"System.Byte\"\r\n bolArray = True<\/span>\r\n Case <\/span>dbSingle: strDatatype = \"System.Single\"\r\n Case <\/span>dbInteger: strDatatype = \"System.Int16\"\r\n Case <\/span>dbBinary\r\n strDatatype = \"System.Byte\"\r\n bolArray = True<\/span>\r\n Case Else<\/span>\r\n bolDatatype = False<\/span>\r\n End Select<\/span>\r\n DataTypeNET = bolDatatype\r\nEnd Function<\/span><\/pre>\nPrimärschlüsselfeld ermitteln<\/h2>\n
Public Function <\/span>GetPrimaryKeys(strTable As String<\/span>, strPKs As String<\/span>) As Boolean<\/span>\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>tdf As <\/span>DAO.TableDef\r\n Dim <\/span>idx As <\/span>DAO.Index\r\n Dim <\/span>strPKTemp As String<\/span>\r\n Dim <\/span>i As Integer<\/span>\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> tdf = db.TableDefs(strTable)\r\n For Each idx In tdf.Indexes\r\n If <\/span>idx.Primary Then<\/span>\r\n For i = 0 To idx.Fields.Count - 1\r\n strPKTemp = strPKTemp & idx.Fields(0).Name & \";\"\r\n Next<\/span> i\r\n End If<\/span>\r\n Next<\/span> idx\r\n If <\/span>Len<\/span>(strPKTemp) = 0 Then<\/span>\r\n Exit Function<\/span>\r\n End If<\/span>\r\n strPKs = Left<\/span>(strPKTemp, Len<\/span>(strPKTemp) - 1)\r\n GetPrimaryKeys = True<\/span>\r\nEnd Function<\/span><\/pre>\nPublic Function <\/span>GetPrimaryKey(strTable As String<\/span>, strPK As String<\/span>) As Boolean<\/span>\r\n Dim <\/span>strPKs As String<\/span>\r\n If <\/span>GetPrimaryKeys(strTable, strPKs) = True<\/span> Then<\/span>\r\n If <\/span>InStr<\/span>(1, strPKs, \";\") Then<\/span>\r\n Exit Function<\/span>\r\n Else<\/span>\r\n strPK = strPKs\r\n GetPrimaryKey = True<\/span>\r\n End If<\/span>\r\n Else<\/span>\r\n Exit Function<\/span>\r\n End If<\/span>\r\nEnd Function<\/span><\/pre>\nKlassen und DbSet-Deklarationen zusammenstellen<\/h2>\n
Public Sub <\/span>EDMErstellen()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>tdf As <\/span>DAO.TableDef\r\n Dim <\/span>fld As <\/span>DAO.Field\r\n Dim <\/span>strDbSets As String<\/span>\r\n Dim <\/span>strEntity As String<\/span>\r\n Dim <\/span>strPK As String<\/span>\r\n Dim <\/span>strDatatype As String<\/span>\r\n Dim <\/span>bolArray As Boolean<\/span>\r\n Dim <\/span>strEntities As String<\/span>\r\n Dim <\/span>bolDatatypeExists As Boolean<\/span>\r\n Dim <\/span>strArray As String<\/span>\r\n Set<\/span> db = CurrentDb\r\n For Each tdf In db.TableDefs<\/pre>\n
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Visual Basic Entwickler<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 200 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t