<\/p>\n
Spätestens dann, wenn Sie eine Datenbank zum Kunden geben, gibt es zwei Versionen der gleichen Datenbank. Meist geschieht dies bereits viel früher – zum Beispiel, wenn Sie eine Sicherheitskopie eines bestimmten Entwicklungsstands der Datenbank anfertigen, um ohne Sorge änderungen vornehmen zu können. Was aber, wenn Sie etwa nach Arbeiten am Datenmodell noch einmal prüfen möchten, wie die Unterschiede zum Datenmodell einer anderen Version der Datenbank aussehen Genau: Dann hilft Ihnen die Lösung aus dem vorliegenden Beitrag weiter.<\/b><\/p>\n
Datenmodell ändern<\/b><\/p>\n
Es kann immer mal vorkommen, dass Sie unvorsichtigerweise änderungen am Datenmodell vornehmen. Sie sollten dann anschließend allerdings noch nachvollziehen können, welche änderungen dies waren. Aber wie das im Entwickleralltag so ist, gerät man in einem Programmierrausch und vergisst, die änderungen zu dokumentieren. Schwamm drüber: Wenn sich die Möglichkeit bietet, änderungen im Nachhinein durch einen Vergleich nachvollziehen zu können, kann man sich die Dokumentation doch sparen. Fehlt also nur noch ein geeignetes Tool, um die Datenmodelle zweier Datenbanken abzugleichen. Und dieses programmieren wir in diesem Beitrag.<\/p>\n
Vorgehensweise<\/b><\/p>\n
Es gibt verschiedene Vorgehensweisen für den Vergleich zweier Datenmodelle. Man könnte Tabelle für Tabelle, Feld für Feld und Eigenschaft für Eigenschaft durchlaufen und änderungen herausschreiben. Alternativ schreibt man erstmal den Status Quo der aktuellen und der ursprünglichen Datenbank in Tabellen und vergleicht diese dann. In diesem Beitrag wollen wir die letztere Variante ausprobieren: Nach der Auswahl der Datenbanken sollen deren Informationen gleich in einem Satz von Tabellen landen. Nach dem Einlesen dieser Informationen für die betroffenen Datenbanken durchlaufen wir dann die angefallenen Daten. <\/p>\n
Die Anwendung im Einsatz<\/b><\/p>\n
Bild 1 zeigt das Formular der Lösung zu diesem Beitrag in der Formularansicht. Das Formular besteht aus den folgenden Elementen:<\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_001.png\")
<\/p>\n
Bild 1: Die Lösung zum Vergleichen von Datenmodellen<\/span><\/b><\/p>\n Datenmodell der Lösung<\/b><\/p>\n Das Datenmodell ist hierarchisch aufgebaut. Die oberste Ebene nimmt die die Tabelle tblDatenbanken <\/b>ein, die aus den beiden Feldern DatenbankID <\/b>und Datenbank <\/b>besteht, wobei Datenbank-ID <\/b>den Part des Primärschlüsselfeldes übernimmt (s. Bild 2).<\/p>\n Bild 2: Entwurf der Tabelle tblDatenbanken<\/span><\/b><\/p>\n Die Tabelle tblTabellen <\/b>nimmt alle Tabellen der beiden beteiligten Datenbanken auf. Dazu stellt sie die Felder TabelleID <\/b>als Primärschlüsselfeld, Tabelle <\/b>mit dem Tabellennamen sowie Systemtabelle <\/b>und VersteckteTabelle <\/b>als Ja\/Nein<\/b>-Felder, die anzeigen, ob die Tabelle eine Systemtabelle oder eine versteckte Tabelle ist, zur Verfügung. Außerdem referenziert sie über das Fremdschlüsselfeld Datenbank-ID <\/b>die Tabelle tblDatenbanken<\/b> und legt somit fest, zu welcher Datenbank die Tabelle gehört (s. Bild 3).<\/p>\n Bild 3: Entwurf der Tabelle tblTabellen<\/span><\/b><\/p>\n Die einzelnen Felder einer jeden Tabelle speichert die Anwendung in der Tabelle tblFelder <\/b>(s. Bild 4). Neben dem Primärschlüsselfeld FeldID <\/b>und dem Feld Feld <\/b>zum Speichern des Feldnamens enthält auch diese Tabelle wieder ein Fremdschlüsselfeld zum Herstellen der übergeordneten Beziehung, in diesem Fall zur Tabelle tblTabellen<\/b>.<\/p>\n Bild 4: Entwurf der Tabelle tblFelder<\/span><\/b><\/p>\n Nun fehlen noch die Eigenschaften der Tabelle sowie der einzelnen Felder. Diese speichert die Anwendung in zwei weiteren Tabellen. Die Tabelle tblTabelleneigenschaften <\/b>speichert alle Eigenschaften der mit dem Fremdschlüsselfeld TabelleID <\/b>referenzierten Tabelle aus tblTabellen<\/b>, die Tabelle tblFeldeigenschaften <\/b>erledigt das Gleiche für die Felder. Dabei enthält die Tabelle tblTabelleneigenschaften <\/b>neben dem Primär- und dem Fremdschlüsselfeld noch zwei Felder namens Tabelleneigenschaft <\/b>und Eigenschaftswert <\/b>(s. Bild 5).<\/p>\n Bild 5: Entwurf der Tabelle tblTabelleneigenschaften<\/span><\/b><\/p>\n In der Tabelle tblFeldeigenschaften <\/b>heißen die entsprechenden Felder Feldeigenschaft <\/b>und Eigenschaftswert <\/b>(s. Bild 6).<\/p>\n Bild 6: Entwurf der Tabelle tblFeldeigenschaften<\/span><\/b><\/p>\n Referenzielle Integrität mit Löschweitergabe<\/b><\/p>\n Im überblick sieht das Datenmodell wie in Bild 7 aus. Wichtig ist an dieser Stelle, dass wir für alle Beziehungen zwischen den Tabellen referenzielle Integrität mit Löschweitergabe definiert haben. Wenn die nachfolgenden Routinen dann einen Datensatz der Tabelle tblDatenbanken <\/b>löschen, um die Daten zu dieser Datenbank erneut einzulesen, entfernt Access automatisch auch die Daten aller damit verknüpften Tabellen.<\/p>\n Bild 7: Datenmodell der Anwendung in der übersicht<\/span><\/b><\/p>\n Optionen speichern<\/b><\/p>\n Das Formular ist an die Tabelle tblOptionen <\/b>gebunden. Diese enthält Felder wie Datei1<\/b>, Datei2<\/b>, SystemtabellenEinlesen <\/b>und VersteckteTabellenEinlesen<\/b>. Die Textfelder txtDatei1 <\/b>und txtDatei2 <\/b>sowie die Kontrollkästchen chkSystemtabellen <\/b>und chkVersteckteTabellen <\/b>sind an diese Felder gebunden. Auf diese Weise merkt sich die Lösung die zuletzt verwendeten Einstellungen, was gerade beim Entwickeln einer solchen Lösung praktisch ist.<\/p>\n Datenmodell einlesen<\/b><\/p>\n Nachdem die Tabellen zum Erfassen der Elemente des Datenmodells, also Datenbanken, Tabellen, Felder, Tabelleneigenschaften und Feldeigenschaften, erstellt sind, können wir uns an die Füllung derselben begeben. Dies geht mit der Vorstellung einiger Details des Formulars frmDatenmodellVergleichen <\/b>einher, das im Entwurf wie in Bild 8 aussieht.<\/p>\n Bild 8: Das Formular frmDatenmodellVergleichen in der Entwurfsansicht<\/span><\/b><\/p>\n Die Schaltfläche cmdDatei1<\/b> ruft beim Anklicken die Prozedur aus Listing 1 auf. Diese Prozedur verwendet die Funktion OpenFileName<\/b>, die Sie im Modul mdlTools <\/b>der Datenbank finden, um einen Datei öffnen<\/b>-Dialog anzuzeigen, mit dem der Benutzer die erste der beiden zu vergleichenden Datenbanken auswählt. Wenn der Benutzer im Dialog die Abbrechen<\/b>-Taste betätigt, wird Me!txtDatei <\/b>geleert. Die anschließende Auswertung des Inhalts von txtDatei1 <\/b>mit der Dir<\/b>-Funktion und der Vergleich der Länge der ermittelten Zeichenkette liefert nur den Wert True<\/b>, wenn es sich um eine gültige Datei handelt. Nur in diesem Fall ruft die Prozedur dann die Routine DatenbankEinlesen <\/b>mit dem Pfad zur Datei als Parameter auf.<\/p>\n Die zweite Schaltfläche cmdDatei2 <\/b>arbeitet fast genauso – der einzige Unterschied ist, dass sie das Textfeld txtDatei2 <\/b>füllt.<\/p>\n Datenbank einlesen<\/b><\/p>\n Die Routine DatenbankEinlesen<\/b>, die den Pfad zur einzulesenden Datenbank als Parameter erwartet, aktiviert zunächst die Sanduhr, da der Vorgang bereits für kleinere Datenmodelle ein paar Sekunden dauern kann (in aktuellen System erscheint natürlich längst keine Sanduhr mehr – aber Sie wissen ja, was gemeint ist). Die Prozedur deklariert zwei Database<\/b>-Variablen: db <\/b>referenziert die aktuelle Datenbank, um mit der Execute<\/b>-Methode Datensätze zur Tabelle zum Speichern der Unterschiede hinzufügen zu können, dbQuelle <\/b>referenziert die zu untersuchende Datenbank.<\/p>\n Diese Datenbank öffnet die Prozedur mit der OpenDatabase<\/b>-Methode. Sie übergibt dieser Methode den Pfad zur Datenbank sowie den Wert True <\/b>für den Parameter ReadOnly<\/b>. Dann löscht sie alle Datensätze aus der Tabelle tblDatenbanken<\/b>, deren Feld Datenbank<\/b> den Pfad der hinzuzufügenden Datenbank enthält.<\/p>\n Anschließend legt sie gleich einen entsprechenden neuen Datensatz in der Tabelle tblDatenbanken <\/b>an und ermittelt mit der Abfrage SELECT @@IDENTITY <\/b>den Primärschlüsselwert des neu hinzufügten Datensatzes. Dieser wird später zum Anlegen der Datensätze in der verknüpften Tabelle tblTabellen<\/b> benötigt. Der Aufruf der Routine TabellenEinlesen <\/b>startet das Einlesen der Tabellen der soeben geöffneten Datenbank. Ist dieser Vorgang, der alle weiteren Aktionen anstößt, abgeschlossen, lässt die Prozedur die Sanduhr wieder verschwinden.<\/p>\n Tabellen einlesen<\/b><\/p>\n Die Prozedur TabellenEinlesen <\/b>erwartet Verweise auf die beiden betroffenen Datenbanken, also die aktuelle und die zu untersuchende Datenbank, sowie den Primärschlüsselwert des zuvor in der Tabelle tblDatenbanken <\/b>angelegten Datensatzes (s. Listing 3). Die Prozedur durchläuft in einer Schleife alle Elemente der TableDefs<\/b>-Auflistung des mit dbQuelle <\/b>referenzierten Database<\/b>-Objekts. Dabei stellt sie jeweils zunächst die Variable bolEinlesen <\/b>auf den Wert True <\/b>ein und gibt einen Status über den aktuellen Bearbeitungsstand in der Statusleiste aus.<\/p>\n Wenn Systemtabellen ignoriert werden sollen, die aktuell mit tdf <\/b>referenzierte Tabelle aber eine Systemtabelle ist, wird bolEinlesen <\/b>auf False <\/b>eingestellt – das geschieht ähnlich für versteckte Tabellen<\/b>. Ob es sich um eine Systemtabelle oder um eine versteckte Tabelle handelt, erfahren wir durch einen Vergleich des Wertes der Eigenschaft Attributes <\/b>der Tabelle mit dem Wert der Konstanten dbSystemobject <\/b>beziehungsweise dbHiddenObject<\/b>. Hat bolEinlesen <\/b>anschließend noch den Wert True<\/b>, fügt die Prozedur der Tabelle tblTabellen <\/b>einen entsprechenden Datensatz hinzu und speichert den Wert des Primärschlüsselfeldes des neuen Datensatzes in der Variablen lngTabelleID<\/b>. Anschließend ruft sie die beiden Prozeduren FelderEinlesen <\/b>und TabelleneigenschaftenEinlesen <\/b>auf.<\/p>\n <\/p>\n Felder einlesen<\/b><\/p>\n Die erste der beiden genannten Prozeduren erwartet wiederum zwei Objektvariablen. Dabei handelt es sich wiederum um den Verweis auf die aktuelle Datenbank.<\/p>\n Die Quelldatenbank ist diesmal nicht gefragt, denn wir benötigen ja Zugriff auf die Felder der übergeordneten Tabelle. Daher übergeben wir mit tdf<\/b> einen Verweis auf das entsprechende TableDef<\/b>-Objekt und außerdem den Primärschlüsselwert des zuvor angelegten Datensatzes der Tabelle tblTabellen<\/b>.<\/p>\n Die Prozedur FelderAnlegen<\/b> durchläuft schlicht über die Variable fld <\/b>die Fields<\/b>-Auflistung des TableDef<\/b>-Objekts tdf<\/b>. Dabei aktualisiert sie wiederum die Statuszeile von Access, trägt einen entsprechenden Datensatz in die Tabelle tblFelder <\/b>ein, ermittelt den Primärschlüsselwert des neuen Datensatzes und ruft dann die Prozedur auf, die sich um das Speichern der Eigenschaften der Felder kümmert (s. Listing 4).<\/p>\n Feldeigenschaften einlesen<\/b><\/p>\n Die Prozedur FeldeigenschaftenEinlesen wird nun für jedes Feld einmal aufgerufen.<\/p>\n Damit wir in der Statusmeldung einen Ausdruck der Form Tabelle Die Prozedur durchläuft alle Elemente der Properties<\/b>-Auflistung des Field<\/b>-Objekts. Diesmal sollen ja nicht nur Namen gespeichert werden – wie bei der Datenbank, den Tabellen und den Feldern, – sondern die Bezeichnungen der Eigenschaften sowie die entsprechenden Werte. Bei den Eigenschaften des Field<\/b>-Objekts gibt es die folgende Besonderheit: Das Field<\/b>-Objekt kommt gleich an mehreren Stellen im DAO<\/b>-Objektmodell vor. Allerdings werden nicht alle Eigenschaften des Field<\/b>-Objekts, die über die Properties<\/b>-Auflistung verfügbar sind, in jedem Kontext genutzt.<\/p>\n So fallen etwa beim Field<\/b>-Objekt der Fields<\/b>-Auflistung einer Tabelle die Eigenschaften FieldSize<\/b>, ForeignName<\/b>, OriginalValue<\/b>, ValidateOnSet<\/b>, Value <\/b>und VisibleValue <\/b>unter den Tisch. Und nicht nur das: Wenn Sie versuchen, auf diese Eigenschaften über die Properties<\/b>-Auflistung zuzugreifen, löst dies einen Fehler aus. Also prüfen wir vorab den Namen des aktuellen Elements der Properties<\/b>-Auflistung in einer Select Case<\/b>-Bedingung und ignorieren so die oben genannten Elemente.<\/p>\n Schließlich schreibt die Prozedur für jede Eigenschaft des Tabellenfeldes einen neuen Datensatz in die Tabelle tblFeldeigenschaften<\/b>. Den neuen Primärschlüsselwert müssen wir uns nicht mehr merken, denn es gibt keine untergeordneten Elemente mehr.<\/p>\n Tabelleneigenschaften einlesen<\/b><\/p>\n Fehlt nur noch eine Art von Information: Die Eigenschaften der Tabellen selbst. Diese ermittelt die Prozedur TabelleneigenschaftenEinlesen<\/b> aus Listing 6. Diese durchläuft wiederum alle Property<\/b>-Elemente der Properties<\/b>-Aufistung des TableDef<\/b>-Objekts.<\/p>\n Hier gibt es eine Besonderheit: Es kann nämlich vorkommen, dass Eigenschaften wie NameMap <\/b>den Datentyp dbLongBinary <\/b>aufweisen, deren Inhalt sich nicht so einfach in ein Textfeld schreiben lässt. Deshalb ignoriert die Prozedur nach einer Prüfung auf prp.Type = dbLongBinary <\/b>gleich komplett.<\/p>\n Die Namen und Werte der Eigenschaften landen dann per INSERT INTO<\/b>-Aktionsabfrage wie gewohnt in der Zieltabelle, in diesem Fall tblTabelleneigenschaften<\/b>.<\/p>\n Datenmodell vergleichen<\/b><\/p>\n Um die durch die nachfolgend beschriebenen Prozeduren ermittelten Unterschiede zwischen den Datenmodellen der beiden Datenbanken zu speichern und diese schließlich im Unterformular sfmDatenmodellVergleichen <\/b>anzuzeigen, müssen diese Informationen selbst in einer Tabelle gespeichert werden.<\/p>\n Diese Tabelle heißt tblUnterschiede<\/b> und sieht im Entwurf wie in Bild 9 aus. Hier ist zu erläutern, dass es verschiedene Arten von Eintragungen geben wird, die Sie auch in Bild 10 wiederfinden: Wenn beispielsweise eine Tabelle in der einen Datenbank enthalten ist, in der anderen jedoch nicht, wird im Feld Tabelle <\/b>der Tabellenname vermerkt. Je nachdem, ob die Tabelle in Datenbank1 <\/b>oder in Datenbank2 <\/b>vorliegt, wird in die entsprechenden Felder entweder der Eintrag Vorhanden <\/b>oder .\/. <\/b>eingetragen.<\/p>\n Bild 9: Die Tabelle zum Speichern der Unterschiede zwischen den Datenmodellen<\/span><\/b><\/p>\n Bild 10: Einige Beispieldatensätze in der Tabelle tblUnterschiede<\/span><\/b><\/p>\n Enthält eine Tabelle ein Feld, das in der gleichnamigen Tabelle der anderen Datenbank nicht enthalten ist, landen Tabellen- und Feldname in den ersten beiden Feldern der Datenbank, die Felder Datenbank1 <\/b>und Datenbank2 <\/b>nehmen wiederum die Werte Vorhanden <\/b>oder .\/. <\/b>auf.<\/p>\n Wenn sich die Werte einer Eigenschaft zweier gleichnamiger Tabellen unterscheiden, enthält der entsprechende Datensatz den Namen der Tabelle und der Eigenschaft sowie die Eigenschaftswerte in den Feldern Datenbank1 <\/b>und Datenbank2<\/b>. Genauso sieht es bei den Eigenschaften von Tabellenfeldern aus – mit dem Unterschied, dass dann zusätzlich der Feldname in das Feld Feld <\/b>eingetragen wird.<\/p>\n Prozedur zum Vergleichen der Tabellen<\/b><\/p>\n Die erste Prozedur wird durch das Betätigen der Schaltfläche cmdVergleichen <\/b>des Formulars frmDatenmodellVergleichen <\/b>aufgerufen und sieht wie in Listing 7 aus. Die Prozedur leert die Tabelle tblUnterschiede <\/b>und ermittelt dann per DLookup <\/b>die Primärschlüsselwerte der beiden zu vergleichenden Datenbanken.<\/p>\n Der Vergleich der beiden Datenmodelle ist hauptsätzlich auf den Einsatz von Abfragen statt auf VBA aufgebaut. Wir erläutern den Einsatz anhand der Abfragen zum Vergleichen der Tabellen der beiden Datenbanken.<\/p>\n Und das funktioniert so: Wir verwenden zwei Abfragen namens qryTabellenDatei1 <\/b>und qryTabellenDatei2 <\/b>als Grundlage. Beide liefern exakt die Felder der Tabelle tblTabellen<\/b>. Allerdings enthält jeweils das Feld DatenbankID <\/b>einen Parameter als Kriterium – DatenbankID1 <\/b>bei der ersten, DatenbankID2 <\/b>bei der zweiten Datenbank (s. Bild 11). Die eine Abfrage liefert also alle Tabellen der ersten Datenbank, die andere die der zweiten. Was fangen wir nun damit an Wir erstellen eine weitere Abfrage, welche die ersten beiden Abfragen aufnimmt (s. Bild 12). Die beiden Abfragen der Datenherkunft verknüpfen wir dann über das Feld Tabelle <\/b>miteinander. Dabei stellen Sie die Verknüpfungseigenschaften so ein, dass auf jeden Fall alle Datensätze der ersten Abfrage angezeigt werden. Enthält die zweite Abfrage keinen passenden Datensatz, soll die Abfrage hier einfach leere Felder liefern. Im aktuellen Zustand würde die Abfrage bei einer überzähligen Tabelle in der ersten Datenbank zwar den Datensatz der Abfrage qryTabellenDatei1 <\/b>liefern, aber keinen für die Abfrage qryTabellenDatei2<\/b>. Das Feld Tabelle <\/b>der zweiten Abfrage bliebe also leer. Und das machen wir uns zunutze: Wir prüfen den Inhalt dieses Feldes per Kriterium gegen den Wert Null<\/b>. Die Abfrage liefert also nur solche Tabellen-Datensätze, die in der ersten Datenbank vorkommen, aber nicht in der zweiten. Nun müssen wir nur noch Datensätze dieser Tabelle durchlaufen und jeweils einen Datensatz zur Tabelle tblUnterschiede <\/b>hinzufügen. Das erledigen die folgenden Anweisungen der Prozedur cmdVergleichen_Click<\/b>.<\/p>\n Bild 11: Ermittlung aller Tabellen, die zwar in der ersten, nicht aber in der zweiten Datenbank enthalten sind<\/span><\/b><\/p>\n Bild 12: Diese Abfragen bilden die Grundlage zum Ermitteln von Tabellen, die nur in einer Datenbank vorkommen.<\/span><\/b><\/p>\n Da die in der Abfrage qryTabellenDatei1NichtDatei2 <\/b>Parameter enthält, müssen wir diese zunächst per VBA füllen. Dies erledigen wir, indem wir zunächst ein neues QueryDef<\/b>-Objekt auf Basis dieser Abfrage erstellen.<\/p>\n Dann legen wir nacheinander zwei Parameter<\/b>-Objekte namens prm <\/b>an und füllen diese mit Verweisen auf die Namen der verwendeten Parameter, also DatenbankID1 <\/b>und DatenbankID2<\/b>. Dann füllen wir die Parameter durch Zuweisung der in den Variablen lngDatenbank1 <\/b>und lngDatenbank2 <\/b>gespeicherten Werte an die Eigenschaft Value <\/b>des Objekts prm<\/b>. Wenn Sie nun die OpenRecordset<\/b>-Methode des QueryDef<\/b>-Objekts ausführen, erhalten Sie ein Recordset-<\/b>Objekt mit allen gefundenen Datensätzen.<\/p>\n Diese durchläuft die Prozedur in einer Do While<\/b>-Schleife und fügt für jeden Datensatz mit der AddNew<\/b>-Methode einen neuen Datensatz zur Tabelle tblUnterschiede <\/b>hinzu. Das Feld Tabelle <\/b>erhält den Namen der überzähligen Tabelle, Datenbank1 <\/b>wird mit Vorhanden <\/b>und Datenbank2 <\/b>mit .\/. <\/b>gefüllt. Schließlich speichert die Prozedur den neuen Datensatz mit der Update<\/b>-Methode.<\/p>\n Auf die gleiche Weise müssen wir anschließend eigentlich auch bei den Tabellen vorgehen, die in der zweiten Datenbank vorhanden sind, aber nicht in der ersten. Die dazu benötigte Abfrage sieht wie in Bild 13 aus.<\/p>\n Bild 13: Ermittlung aller Tabellen, die nur in der zweiten Datenbank enthalten sind<\/span><\/b><\/p>\n Die Abfrage setzt die Verknüpfungseigenschaften genau andersherum und gibt die beiden Felder TabelleID <\/b>und Tabelle <\/b>der Abfrage qryTabellenDatei2 <\/b>der Datenherkunft aus.<\/p>\n Die Codezeilen zum Durchlaufen dieser Abfrage und zum Anlegen der entsprechenden Datensätze in der Tabelle tblUnterschiede <\/b>können analog zum Einlesen der Unterschiede aus dem vorherigen Teil erstellt werden.<\/p>\n Optimierungsbedarf<\/b><\/p>\n Für diesen Vorgang, also das öffnen eines Recordset mit Parametern und das anschließende übernehmen der gefundenen Daten in die Tabelle tblUnterschiede<\/b>, haben wir nun rund 16 Zeilen Code benötigt. Das Gleiche geschieht nun nochmals für die Tabellen, die nur in der zweiten Datenbank enthalten sind.<\/p>\n Außerdem benötigen wir ähnliche Konstrukte (inklusive entsprechender Abfragen), um zu ermitteln, welche Tabellen in beiden Datenbanken enthalten sind. Dieses Recordset wird dann die Grundlage für den Vergleich der weiteren Elemente und Eigenschaften sein – nämlich der Tabelleneigenschaften, Tabellenfelder und der Feldeigenschaften. Dies ist eine Menge Code, der sich erstens fast in gleicher Form ständig wiederholt und der zweitens eine Menge DAO-Aktualisierungen innerhalb von Do While<\/b>-Schleifen durchführt. In den Beiträgen Parameterabfragen unter der Lupe <\/b>(www.access-im-unternehmen.de\/910<\/b>) und Aktionsabfragen statt Schleifen <\/b>(www.access-im-unternehmen.de\/911<\/b>) erfahren Sie, wie wir dies optimiert und auf wenige Zeilen Code reduziert haben.<\/p>\n Auf diese Weise wird aus den 16 Zeilen ein Einzeiler mit einer geänderten Abfrage und einer kleinen Hilfsfunktion.<\/p>\n Gleichnamige Tabellen ermitteln<\/b><\/p>\n Damit wir die Tabelleneigenschaften sowie die Tabellenfelder vergleichen können, müssen wir zunächst alle Tabellen ermitteln, die in beiden Datenbanken enthalten sind. Die dazu verwendete Abfrage nutzt wiederum die beiden Abfragen qryTabellenDatei1 <\/b>und qryTabellenDatei2 <\/b>als Datenherkunft.<\/p>\n Sie sieht wie in Bild 14 aus und ermittelt alle Datensätze der beiden Herkunftsabfragen, deren Feld Tabelle <\/b>den gleichen Wert enthält. Davon gibt sie die Primärschlüsselwerte aus sowie den Tabellennamen aus einer der beiden Abfragen – welche, ist egal, da die Werte ja ohnehin gleich sind. Wichtig ist, dass wir die Namen der Felder zur Ausgabe der TabellenID <\/b>umbenennen, und zwar mit folgenden Ausdrücken:<\/p>\n Bild 14: Ermittlung der gemeinsamen Tabellen der beiden Datenbanken<\/span><\/b><\/p>\n Auch für das Ergebnis dieser Abfrage holt die Prozedur sich ein Recordset und durchläuft alle Datensätze in einer Do While<\/b>-Schleife. Darin ruft sie für jede Tabelle je einmal die Prozeduren FelderVergleichen <\/b>und TabelleneigenschaftenVergleichen <\/b>auf.<\/p>\n Tabelleneigenschaften vergleichen<\/b><\/p>\n Der Vergleich der Tabelleneigenschaften erfolgt etwas anders als der Abgleich der Tabellen, die nur in der einen oder in der anderen Datenbank enthalten sind.<\/p>\n Der Grund ist, dass es ja nicht nur Eigenschaften gibt, die nur in einer der beiden Datenbanken enthalten sind, sondern auch solche, die zwar in einer Tabelle in beiden Datenbanken vorkommen, aber verschiedene Werte haben. Das heißt, dass wir drei Vergleiche vornehmen müssen:<\/p>\n Dazu benötigen wir zunächst zwei Abfragen, welche die Eigenschaften der Tabelle aus der ersten und der aus der zweiten Datenbank liefern. Die erste sieht wie in Bild 15 aus.<\/p>\n Bild 15: Ermittlung aller Eigenschaften einer Tabelle mit einem bestimmten Wert im Feld TabelleID<\/span><\/b><\/p>\n Das Ergebnis dieser Abfrage finden Sie am Beispiel der Tabelle tblArtikel <\/b>in Bild 16.<\/p>\n Bild 16: Eigenschaften einer Tabelle mit Werten<\/span><\/b><\/p>\n Die Abfrage qryTabelleneigenschaftenDatei1NichtDatei2 <\/b>ermittelt nach bewährter Manier die Eigenschaften, die nur die Tabelle in der ersten Datenbank enthält, nicht aber die in der zweiten Datenbank, die Abfrage qryTabelleneigenschaftenDatei2NichtDatei1 <\/b>erledigt dies für den umgekehrten Fall.<\/p>\n Interessant ist die Abfrage tblTabelleneigenschaftenVergleich<\/b>. Sie sieht wie in Bild 17 aus und enthält die beiden Basisabfragen zur Ermittlung der Tabelleneigenschaften für die erste und die zweite Datenbank.<\/p>\n Bild 17: Eigenschaften einer Tabelle in zwei Datenbanken vergleichen<\/span><\/b><\/p>\n Sie gibt den Namen der Eigenschaft sowie den Wert in der ersten und der zweiten Tabelle zurück. Dabei greift allerdings ein Kriterium, das nur diejenigen Datensätze zurückgibt, deren Wert im Feld Eigenschaftswert <\/b>der ersten Tabelle nicht mit dem Wert im gleichen Feld der zweiten Tabelle übereinstimmt. Die beiden Eigenschaftswerte werden dann als Wert1 <\/b>und Wert2 <\/b>ausgegeben.<\/p>\n Die Prozedur TabelleneigenschaftenVergleichen <\/b>aus Listing 8 verwendet gegenüber der Art und Weise, wie wir in cmdVergleichen_Click <\/b>vorgegangen sind, bereits eine verbesserte Version.<\/p>\n Sie erstellt zunächst mithilfe der Funktion RecordsetAusParameterabfrage<\/b>, die im Beitrag Parameterabfragen unter der Lupe <\/b>(www.access-im-unternehmen.de\/910<\/b>) erläutert wird, drei Recordsets auf Basis der Abfragen qryTabelleneigenschaftenDatei1NichtDatei2<\/b>, qryTabelleneigenschaftenDatei2NichtDatei1 <\/b>und qryTabelleneigenschaften <\/b>und durchläuft diese in Do While<\/b>-Schleifen. Darin schreibt sie, ebenfalls in einer Weiterentwicklung der zuvor genutzten DAO<\/b>-Befehle AddNew <\/b>und Update<\/b>, mit einer per Execute <\/b>ausgeführten INSERT INTO<\/b>-Abfrage die gefundenen Daten in die Tabelle tblUnterschiede<\/b>.<\/p>\n Felder vergleichen<\/b><\/p>\n Nun folgen die Felder. Diese vergleichen wir in der Prozedur FelderVergleichen <\/b>zunächst anhand des Namens. Die Prozedur FelderVergleichen <\/b>erwartet einen Verweis auf das Database<\/b>-Objekt, den Primärschlüsselwert für die Tabelle der ersten und für die der zweiten Datenbank sowie den Namen der Tabelle als Parameter.<\/p>\n Hier finden Sie einen weiteren Evolutionsschritt vor: Statt der langwierigen Ermittlung des Recordsets auf Basis einer Parameterabfrage und dem anschließenden Durchlaufen des Recordsets, um die Unterschiede in die Tabelle tblUnterschiede <\/b>einzutragen, finden Sie hier nur noch den Aufruf einer einzigen Prozedur namens AktionsabfragenMitParameter<\/b>. Dazu ist auch die Erstellung von Aktionsabfragen statt Auswahlabfragen nötig, aber dies besprechen wir im Beitrag Aktionsabfragen statt Schleifen <\/b>(www.access-im-unternehmen.de\/911<\/b>).<\/p>\n Die Felder einer Tabelle werden ähnlich abgeglichen wie die Tabellen einer Datenbank weiter oben: Wir erstellen je eine Abfrage, die alle Felder ermittelt, die in der Tabelle der ersten Datenbank vorkommen, aber nicht in der zweiten und umgekehrt. Diesmal verwenden wir allerdings direkt eine Aktionsabfrage und führen diese aus.<\/p>\n Außerdem benötigen wir noch eine Auswahlabfrage, die alle Felder liefert, die in beiden Versionen der aktuell zu untersuchenden Tabelle vorkommen.<\/p>\n Zu diesen legen wir zunächst keine Daten in der Tabelle tblUnterschiede <\/b>an, aber wir rufen zu jedem dieser Felder die Prozedur FeldeigenschaftenVergleichen <\/b>auf. Und diese vergleicht, genau wie bereits bei den Tabelleneigenschaften, die Eigenschaften der einzelnen Felder miteinander.<\/p>\n Feldeigenschaften vergleichen<\/b><\/p>\n Der letzte Vergleich bezieht sich auf die einzelnen Feldeigenschaften. Dazu gehört beispielsweise auch der Felddatentyp. Auch für diesen Vergleich erstellen wir wieder zwei Abfragen, welche die Eigenschaften erfassen, die in der ersten, aber nicht in der zweiten Datenbank enthalten sind und umgekehrt. Diese heißen nun qryFeldeigenschaftenDatei1 <\/b>und qryFeldeigenschaftenDatei2<\/b>.<\/p>\n Auf Basis dieser beiden Abfragen erstellen wir drei Aktionsabfragen (wir wollen diesmal eine höhere Evolutionsstufe wie in Aktionsabfragen statt Schleifen <\/b>(www.access-im-unternehmen.de\/911<\/b>) beschrieben erklimmen).<\/p>\n Die erste Abfrage, die alle Feldeigenschaften eines Feldes der ersten Datenbank liefern soll, die nicht in der zweiten Datenbank enthalten sind, sieht wie in Bild 18 aus. Da wir auch den Tabellennamen und den Feldnamen in die Tabelle tblUnterschiede <\/b>eintragen wollen, haben wir gegenüber den vorherigen Abfragen noch die beiden Tabellen tblTabellen <\/b>und tblFelder <\/b>hinzugefügt. Diese liefern mit den Feldern Tabelle <\/b>und Feld <\/b>die fehlenden Werte. Diese Felder werden, wie bei einer Anfüge- oder INSERT INTO<\/b>-Abfrage üblich, dem Zielfeld zugewiesen. Gleiches geschieht mit dem Feld Feldeigenschaft<\/b>. Als Eigenschaftswerte verwenden wir den Wert des Feldes Eigenschaftswert <\/b>der Abfrage qryFeldeigenschaftenDatei1 <\/b>sowie den Ausdruck .\/. <\/b>für die Datenbank, in der die entsprechende Eigenschaft nicht verwendet wird. In der Abfrage qryINSERTINTOFeldeigenschaftenDatei2NichtDatei1 <\/b>sieht es umgekehrt aus.<\/p>\n\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_002.png\")
<\/p>\n![\"Entwurf](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_003.png\")
<\/p>\n![\"Entwurf](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_004.png\")
<\/p>\n![\"Entwurf](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_005.png\")
<\/p>\n![\"Entwurf](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_006.png\")
<\/p>\n![\"Datenmodell](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_007.png\")
<\/p>\n![\"Das](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_008.png\")
<\/p>\n![\"Die](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_009.png\")
<\/p>\n![\"Einige](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_010.png\")
<\/p>\n![\"Ermittlung](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_012.png\")
<\/p>\n![\"Diese](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_011.png\")
<\/p>\n![\"Ermittlung](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_013.png\")
<\/p>\n![\"Ermittlung](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_014.png\")
<\/p>\nTabelleID1: TabelleID\r\nTabelleID2: TabelleID<\/pre>\n
\n
![\"Ermittlung](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_015.png\")
<\/p>\n![\"Eigenschaften](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_016.png\")
<\/p>\n![\"Eigenschaften](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_017.png\")
<\/p>\n![\"Aktionsabfrage](\"..\/fileadmin\/_temp_\/2013_06\/pic_916_018.png\")
<\/p>\n