Kategorie: Lösungen

Access-Datenbankanwendungen sind bekanntlich niemals fertig. Das ist an sich kein Nachteil, sondern stellt eher einen Vorteil dar: Im Gegensatz zu fertigen Anwendungen, bei denen Anpassungen entweder gar nicht möglich sind oder viel Geld kosten, kann man Access-Datenbanken einfach selbst um neue Funktionen erweitern. Spannend wird das, wenn die Datenbank von mehreren Nutzern eingesetzt wird. Dann stellt sich die Frage: Wie bekomme ich die neue Version einer Datenbank am einfachsten auf die unterschiedlichen Arbeitsplätze? Das gelingt auf verschiedene Arten, und in diesem Beitrag schauen wir uns eine an, mit der das Update vom Arbeitsplatz des Benutzers aus getriggert werden soll.

Im Beitrag „Besserer Suchen und Ersetzen-Dialog“ haben wir den Dialog zum Suchen und Ersetzen in Access-Formularen nachgebaut und um einige Features ergänzt. Nun wollen wir unseren selbst gebauten Dialog noch für jede Access-Anwendung verfügbar machen. Was liegt da näher, als diessn über das Ribbon aufzurufen? Um eine solche Erweiterung für jede geöffnete Anwendung verfügbar zu machen und so flexibel wie möglich zu sein, verwenden wir dazu ein COM-Add-In. Dieses enthält lediglich die Erweiterung des Ribbons um die benötigten Befehlsschaltlfächen sowie den Code, um von dort aus den „Suchen und Ersetzen“-Dialog zu starten.

Der SQL Server-Tabellenverknüpfungsassistent, den wir im Beitrag „SQL Server-Tabellenverknüpfungsassistent“ (www.access-im-unternehmen.de/1540) vorgestellt haben, funktioniert in vielen Settings bereits recht gut. Die generelle Praxistauglichkeit zeigt sichjedoch erst, wenn die Anwendung einmal auf andere Benutzer und/oder Verwendungszwecke stößt. Da dies nun geschehen ist, wollen wir im zweiten Teil der Beitragsreihe zum Thema SQL Server-Tabellenverknüpfungsassistent einige Änderungen und Erweiterungen nachreichen. Dabei geht es im Wesentlichen um die Benennung der Tabellenverknüpfungen, die von dem Assistenten entweder initial angelegt oder aktualisiert werden sollen.

Die Bordmittel von Access zum Herstellen oder Aktualisieren von Tabellenverknüpfungen zum SQL Server sind teilweise etwas umständlich zu bedienen und erfordern zwangsläufig den Einsatz von Data Source Names (DSN). Diese möchte man unter Umständen aber gar nicht nutzen, sondern einfach alle Informationen in die Verbindungszeichenfolge für die Tabelle schreiben. Natürlich kann man sich ein Set von Tabellen und Formularen zusammenstellen, mit denen man die Verbindungszeichenfolgen und Tabellenverknüpfungen verwaltet. Diese werden dann bei Bedarf der Datenbank hinzugefügt, deren Tabellenverknüpfungen man pflegen möchte. Aber manchmal möchte man einfach nur schnell mal etwas ausprobieren und dazu ist der Aufwand, die Datenbank um diese Tools zu erweitern, zu aufwendig. Wie wäre es also, wenn wir diese Tools einfach in ein Access-Add-In auslagern, mit dem wir unsere Verbindungszeichenfolgen und Verknüpfungen verwalten können? In diesem Beitrag schauen wir uns an, wie dies aussieht.

Das Anlegen von Lastschriften ist eine wichtige Funktion, wenn man Kunden neben Zahlungsarten wie Rechnung, PayPal, Kreditkarte et cetera auch noch die Möglichkeit geben möchte, die Bankverbindung anzugeben, um den Betrag zum Fälligkeitsdatum einfach abbuchen zu lassen. Das ist gerade für wiederkehrende Leistungen wie Abonnements praktisch. Dazu sind jedoch erstens einige Voraussetzungen zu erfüllen wie zum Beispiel das Aktivieren der Möglichkeiten zum Einziehen von Lastschriften und das Beantragen einer sogenannten Gläubiger-Identifikationsnummer. Schließlich benötigen wir noch den passenden VBA-Code. Allein damit kommen wir aber nicht aus: Wenn wir gemütlich von unserer Datenbankanwendung aus Lastschriften anlegen wollen, benötigen wir eine zusätzliche Bibliothek. Dabei handelt es sich um die in vielen Anwendungen verwendete DDBAC-Bibliothek. Wie wir die einzelnen Schritte erledigen, um unsere Anwendung zum Anlegen von Lastschriften verwenden zu können, zeigen wir in diesem Beitrag.

Manche Aufgaben im Alltag eines Access-Entwicklers wiederholen sich immer wieder und unterscheiden sich nur durch Kleinigkeiten. Zum Beispiel sehen Detailformulare, Übersichtsformulare oder auch Formulare zum Verwalten von Daten in Haupt- und Unterformular immer gleich aus – wenn auch für andere Daten. Im Beitrag „Tabellendaten mit Übersicht und Details anzeigen“ (www.access-im-unternehmen.de/1488) haben wir grundsätzlich gezeigt, wie wir ein Hauptformular mit einer Übersicht in einem Unterformular anlegen und programmieren können. Der Beitrag „Detailformular per Mausklick erstellen“ (www.access-im-unternehmen.de/1490) wiederum liefert ein Beispiel dafür, wie wir ein einfaches Detailformular schnell definieren und per Mausklick erstellen können. Im vorliegenden Beitrag wollen wir beides kombinieren – also ein Übersichtsformular mit Haupt- und Unterformular in einem Konfigurationsformular einrichten und dann automatisch erstellen.

Wer kennt das nicht als Entwickler: Man möchte mal eben schnell in einer Tabelle nach einem bestimmten Datensatz suchen. Und das auch noch wiederholt, sodass man immer noch den Filter entfernen und diesen neu setzen muss – wozu wir die eingebauten Filter-Elemente der Datenblattansicht nutzen. Viel schöner wäre es doch, wenn wir mal eben das Kriterium und weitere Einstellungen über das Ribbon steuern könnten – während wir die Daten beim Filtern betrachten. Genau dazu haben wir uns für den Eigenbedarf eine kleine Schnellsuche gebaut, die wir in diesem Beitrag vorstellen. Das Beste: Selbst wenn Sie gar nicht genau erfahren wollen, wir es funktioniert, finden Sie die Lösung für 32-Bit- und 64-Bit-Access im Download zu diesem Beitrag.

Bei der Arbeit mit Microsoft Access gibt es immer wiederkehrende Aufgaben – zum Beispiel das Anlegen von Detailformularen. Diese sollen die Daten aus einfachen Tabellen darstellen und zwei Schaltflächen namens OK und Abbrechen bereitstellen. So kann der Benutzer neue oder geänderte Datensätze übernehmen oder diese verwerfen. Dazu sind immer wieder viele kleine Handgriffe nötig. Damit dies ab jetzt schneller geht, schauen wir uns an, wie wir die meisten der Schritte automatisieren können. Dazu bauen wir ein Formular, mit dem wir alle Konfigurationsschritte erledigen können – von der Auswahl der Datenquelle über die Benennung des Formulars bis hin zur Erstellung des vollständigen Formulars inklusive Code.

In der bisherigen Version der Rechnungsverwaltung haben wir nur eine Kundenadresse gespeichert, die in der Tabelle „tblKunden“ gespeichert war. Im Bestreben, diese Rechnungsverwaltung flexibler zu gestalten, wollen wir in diesem Beitrag zwei Dinge durchführen: Das Aufteilen der Kundentabelle in eine Tabelle mit den Basisdaten des Kunden und mehrere weitere Tabellen zum Speichern der Adressen dieses Kunden sowie das Anpassen des Formulars „frmKundenDetails“ an diese Änderung des Datenmodells. Dies soll die Grundlage bilden, mehrere Adressen je Kunde zu speichern und diese dann nach Bedarf in Bestellungen, Lieferungen, Rechnungen und weitere Vorgänge zu übernehmen.