{"id":55000323,"date":"2016-12-01T00:00:00","date_gmt":"2020-01-24T15:59:38","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=323"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Datenbanken_von_Altlasten_saeubern","status":"publish","type":"post","link":"https:\/\/access-basics.de\/index.php\/Datenbanken_von_Altlasten_saeubern.html","title":{"rendered":"Datenbanken von Altlasten säubern"},"content":{"rendered":"

Dass sich Access-Datenbanken mit der Zeit aufblähen, dürfte jedem Entwickler einmal aufgefallen sein. Beim Löschen von Daten und Objekten, dem Importieren von Objekten aus anderen Datenbanken, Modifikationen an Modulen, dem überschrieben von Objekten, fällt Müll an, der oberflächlich nicht sichtbar ist. über die Ribbon-Funktion Komprimieren und Reparieren<\/b> kann aber ein Teil dieses Mülls leider nicht entfernt werden. Mit recht überschaubarem VBA-Code ändert sich das.<\/p>\n

Beispieldatenbank<\/h2>\n

Die Beispiele dieses Artikels finden Sie in der Datenbank 1606_Saeubern.accdb<\/b>.<\/p>\n

Temporäre Datenbankobjekte<\/h2>\n

Access-Datenbanken können sowohl Tabellen, wie Abfragen, enthalten, die Sie im Navigationsbereich nicht zu Gesicht bekommen. Auf diese möchten wir hier den Fokus setzen.<\/p>\n

Die Beispieldatenbank implementiert vier relational verknüpften Tabellen zu Kundenadressen. Auf diese setzt das Formular frmKunden<\/b> auf (Bild 1). Die Haupttabelle tblKunden<\/b> steht für die Datenherkunft des Formulars, die Detailtabellen tblAnreden<\/b>, tblOrte<\/b> und tblLaender<\/b> werden für die Kombinationsfelder verwendet. Die Steuerelemente kamen durch einfaches Hineinziehen der Vorhandenen Datenfelder<\/b> zustande. Kombinationsfelder ergeben sich deshalb, weil für die Felder IDAnrede<\/b>, IDOrt<\/b> und IDLand<\/b> im Entwurf von tblKunden<\/b> jeweils Nachschlagetabellen<\/b> angegebenen wurden. Also füllt Access hier im Eigenschaftenblatt neben dem Steuerelementinhalt<\/b> auch gleich die passenden Quelltabellen ein und verknüpft die Felder, wie dies aus der Abbildung hervorgeht.<\/p>\n

\"Das<\/a><\/p>\n

Bild 1: Das Kundenformular enthält drei Kombinationsfelder, deren Datenherkunft auf den entsprechenden Detailtabellen basiert<\/p>\n

Grundsätzlich legt Access nun beim Speichern sowohl für das Formular, wie auch für Kombinations- und Listenfelder intern Abfragen an, die weder im Navigationsbereich, noch im Formularentwurf in Erscheinung treten. Doch öffnen Sie einmal die Systemtabelle MSysObjects<\/b>, die einen Katalog aller Datenbankobjekte verzeichnet. Bild 2 zeigt, dass hier vier Abfragen zu sehen sind. Sie werden durch die Spalte Type<\/b> identifiziert, wenn diese den Wert 5<\/b> aufweist. Für die Namen der Abfragen ist jeweils das Präfix ~sq_<\/b> spezifiziert. Folgt darauf ein f<\/b>, so handelt es sich um die Datenherkunft eines Formulars. Access verwendet also nicht die Tabelle tblKunden<\/b> selbst, sondern eine auf ihr beruhende Abfrage für die Daten des Formulars. Der Name des Formulars schließt sich daran an. Für die Datenherkunft von Kombinationsfeldern steht eine ~sq_c<\/b>…-Abfrage. Ihr folgt der Name des Formulars, in dem sich das Kombinationsfeld befindet, und schließlich der Name des Steuerelements, ebenfalls durch ein ~sq_c<\/b>-Präfix gekennzeichnet.<\/p>\n

\"In<\/a><\/p>\n

Bild 2: In der Systemtabelle MSysObjects finden sich die versteckten Abfragen für die Kombinationsfelder des Formulars, beginnend jeweils mit dem Präfix ~sq_<\/p>\n

Diese Abfragen sind über die Oberfläche nicht zu erreichen, wohl aber über DAO! Geben Sie so etwa den SQL-String für die dem Anrede<\/b>-Steuerelement zugrundeliegende Abfrage im VBA-Direktfenster aus:<\/p>\n

  CurrentDB.QueryDefs _\r\n (\" ~sq_cfrmKunden~sq_cIDAnrede\").SQL<\/pre>\n
Sie erhalten dieses Ergebnis:<\/p>\n
SELECT DISTINCTROW *\r\nFROM tblAnreden;<\/pre>\n
Das Formular hat diese Datenherkunft:<\/p>\n
  CurrentDB.QueryDefs _\r\n   (\"~sq_ffrmKunden\").SQL \r\n> \"SELECT DISTINCTROW *\r\nFROM tblKunden;\"<\/pre>\n
Das DISTINCTROW<\/b> sagt der Database Engine<\/b>, dass die zurückgelieferten Datensätze eindeutig sein sollen. Das ist an sich überflüssig, da die Tabellen allesamt einen Primärschlüssel<\/b> aufweisen.<\/p>\n
Entfernten Sie diesen später aber, so könnten auch doppelte identische Datensätze in ihr abgespeichert werden. Hier bekommt das DISTINCTROW<\/b> dann einen Sinn.<\/p>\n
Diese internen Abfragen sind übrigens nicht schreibgeschützt. Sie können ihren SQL-Ausdruck problemlos ändern; etwa so:<\/p>\n
CurrentDB.QueryDefs _\r\n   (\"~sq_ffrmKunden\").SQL = _\r\n\"SELECT * FROM tblKunden\"<\/pre>\n
Diese änderung bleibt auch nach Modifikationen am Formularentwurf erhalten! Es versteht sich von selbst, dass Sie hier nicht unsinnige Ausdrücke einsetzen sollten, um Probleme zu vermeiden.<\/p>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 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
\n\n\t\t\n\t\t