Im Beitrag \u00bbIcons in Access-Formularen und Berichten\u00ab (www.access-im-unternehmen.de\/1235) haben wir schon einmal eine M\u00f6glichkeit aufgezeigt, wir man Formulare und Berichte in Access mit individuellen Icons ausstatten kann. So kann man beispielsweise ein Formular zum Bearbeiten eines Kunden mit dem gleichen Icon ausstatten, das man auch f\u00fcr die Schaltfl\u00e4che zum \u00d6ffnen dieses Formulars im Ribbon untergebracht hat. Der Benutzer kann so noch besser erkennen, worum es im Formular geht. In der vorherigen Fassung der L\u00f6sung hatten wir allerdings noch das Problem, dass wir die Icons, die links oben in Formularen und Berichten erscheinen sollten, noch im Dateisystem speichern mussten. Das kann aus diversen Gr\u00fcnden zu Problem f\u00fchren und daher sind wir froh, hier den n\u00e4chsten Schritt gehen zu k\u00f6nnen: Das direkt Einlesen der Icons aus der Tabelle \u00bbMSysResources\u00ab und anschlie\u00dfendes Anzeigen in Formulare und Berichten.<\/p>\n
Zum Artikel …<\/a><\/p>\n Eine gute Basis f\u00fcr das Anzeigen und Bearbeiten von Daten ist die folgende Konstellation: Wir verwenden ein Haupt- und Unterformular, um die Daten einer Tabelle in einer \u00dcbersichtsansicht anzuzeigen. Dabei k\u00f6nnen wir die Daten, die im Unterformular angezeigt werden, filtern und sortieren. Au\u00dferdem stellen wir Schaltfl\u00e4chen bereit, mit denen wir die Datens\u00e4tze anlegen, bearbeiten und l\u00f6schen k\u00f6nnen. Zum Bearbeiten verwenden wir ein weiteres Formular, das die Daten in einer \u00fcbersichtlichen Ansicht darstellt. Zus\u00e4tzlich f\u00fcgen wir noch ein den Code hinzu, der f\u00fcr das Interagieren der Formulare untereinander notwendig ist. Diese Konstellation von Formularen k\u00f6nnen wir f\u00fcr alle m\u00f6glichen Tabellen verwenden und schaffen so die Basis einer professionellen Anwendung. Anpassungen k\u00f6nnen schlie\u00dflich dort vorgenommen werden, wo m:n- oder 1:n-Beziehungen dargestellt werden sollen.<\/p>\n Zum Artikel …<\/a><\/p>\n Es gibt seit vielen Jahren einen Bug in Access-Formularen, der m\u00f6glicherweise Entwickler und Benutzer in den Wahnsinn treibt. Dabei geht es darum, dass neue oder ge\u00e4nderte Datens\u00e4tze beim Schlie\u00dfen des Formulars nicht automatisch gespeichert werden. Stattdessen findet man neue Datens\u00e4tze einfach nicht in der entsprechenden Tabelle vor und bei vermeintlich ge\u00e4nderten Datens\u00e4tzen wurde die \u00c4nderung nicht \u00fcbernommen. Dies geschieht, wenn man das Formular auf eine bestimmte Art schlie\u00dft und Restriktionen in der zugrunde liegenden Tabelle daf\u00fcr sorgen, dass der Datensatz nicht gespeichert werden kann. Wird zum Beispiel ein Pflichtfeld nicht gef\u00fcllt und das Formular geschlossen, verwirft Access den neuen Datensatz einfach, anstatt eine entsprechende Meldung zu liefern. Dieser Beitrag dokumentiert das Fehlverhalten und zeigt, welche M\u00f6glichkeiten wir zum Umgehen dieses Problems haben.<\/p>\n Zum Artikel …<\/a><\/p>\n Bei der Arbeit mit Microsoft Access gibt es immer wiederkehrende Aufgaben \u2013 zum Beispiel das Anlegen von Detailformularen. Diese sollen die Daten aus einfachen Tabellen darstellen und zwei Schaltfl\u00e4chen namens OK und Abbrechen bereitstellen. So kann der Benutzer neue oder ge\u00e4nderte Datens\u00e4tze \u00fcbernehmen oder diese verwerfen. Dazu sind immer wieder viele kleine Handgriffe n\u00f6tig. Damit dies ab jetzt schneller geht, schauen wir uns an, wie wir die meisten der Schritte automatisieren k\u00f6nnen. Dazu bauen wir ein Formular, mit dem wir alle Konfigurationsschritte erledigen k\u00f6nnen \u2013 von der Auswahl der Datenquelle \u00fcber die Benennung des Formulars bis hin zur Erstellung des vollst\u00e4ndigen Formulars inklusive Code.<\/p>\n Zum Artikel …<\/a><\/p>\n Die einfache Migration der Tabellen einer Datenbank von Access zum SQL Server ist meist schnell erledigt. Der SQL Server Migration Assistant (SSMA) leistet gute Arbeit und schnell landen alle Tabellen in der SQL Server-Datenbank \u2013 samt Erstellung entsprechender Tabellenverkn\u00fcpfungen im Access-Frontend. Damit l\u00e4sst sich erst einmal arbeiten, da die Verkn\u00fcpfungen Lesen und Schreiben der Daten wie gewohnt zulassen. Fr\u00fcher oder sp\u00e4ter wird man jedoch auf Abfragen im Access-Frontend sto\u00dfen, die schlicht zu langsam sind. Und hier kann der SQL Server sein wahres Potential ausspielen: Zum Beispiel, indem wir dort eine Stored Procedure (Gespeicherte Abfrage) anlegen, welche die Abfrage f\u00fcr uns direkt auf dem SQL Server ausf\u00fchrt, was viel schneller gehen wird. Und genau das ist Thema dieses Beitrags: Wie bekommen wir eine mehr oder weniger komplizierte Abfrage als Stored Procedure zum SQL Server und rufen diese von der Access-Datenbank aus auf?<\/p>\nTabellendaten mit \u00dcbersicht und Details anzeigen<\/h3>\n
Formulare: Datensatz wird nicht gespeichert<\/h3>\n
Detailformular per Mausklick erstellen<\/h3>\n
SQL Server: Von der Abfrage zur Stored Procedure<\/h3>\n