Mit den M\u00f6glichkeiten der Datenblattansicht k\u00f6nnen Sie bereits umfassende Filter einsetzen und Sortierungen anwenden. Dazu brauchen Sie nur die Steuerelemente zu nutzen, die bei einem Mausklick auf die Schaltfl\u00e4che mit dem Pfeil nach unten im Spaltenkopf auftauchen. Aber was, wenn Sie immer wieder die gleichen Selektionen ben\u00f6tigen? Sollen Sie dann etwa immer wieder manuell die gleichen Einstellungen vornehmen? Nein, das w\u00e4re nicht die Idee von Access im Unternehmen. Wir zeigen Ihnen im vorliegenden Beitrag, wie Sie die Auswahl in Unterformularen in der Datenblattansichten speichern und einfach wiederherstellen k\u00f6nnen!\u00a0<\/p>\n
Zum Artikel …<\/a><\/p>\n Bei einem Newsletter-Dienstleister habe ich neulich eine tolle M\u00f6glichkeit gesehen, um Daten zusammenzuf\u00fchren. Dabei konnte man aus unterschiedlichen Verteilerlisten eine neue Verteilerliste zusammenstellen. Es war nicht nur m\u00f6glich, Verteilerlisten hinzuzuf\u00fcgen, sondern auch das Ausschlie\u00dfen war eine Option. Man konnte also alle Adressen ausw\u00e4hlen, die in Verteiler A und Verteiler B waren, aber nicht in Verteiler C. Das wollen wir mit Access auch nachbilden! Als Voraussetzung haben wir im Beitrag \u00bbSelektionen speichern\u00ab bereits die M\u00f6glichkeit zum Definieren verschiedener Filter und Sortierungen f\u00fcr die gleiche Tabelle geschaffen. Diese wollen wir nun als Basis zum Zusammenstellen darauf aufbauender Listen verwenden.<\/p>\n Zum Artikel …<\/a><\/p>\n Eine umfangreiche Access-Anwendung kann in ihrem VBA-Projekt einige API-Deklarationen enthaltenen. Je l\u00e4nger diese Anwendung bereits entwickelt wird, desto mehr solcher Deklarationen haben sich im Laufe der Zeit in vielen verschiedenen Modulen angesammelt. Und umso mehr dieser APIs werden vielleicht gar nicht mehr verwendet, weil man sie grunds\u00e4tzlich nicht mehr braucht oder sie durch andere Funktionen oder DLLs ersetzt hat. Daher ist es grunds\u00e4tzlich interessant, nicht mehr verwendete Deklarationen von API-Funktionen aus der Anwendung zu entfernen. Noch interessanter wird dies, wenn die Migration einer f\u00fcr 32-Bit-Access ausgelegten Anwendung zu einer Anwendung\u00a0ansteht, die auch unter 64-Bit-Access ihren Dienst tun soll. Je weniger API-Funktionen dann deklariert sind, umso weniger Anpassungen sind notwendig. Im vorliegenden Beitrag schauen wir uns zun\u00e4chst an, wie Sie die API-Deklarationen und die gegebenenfalls ben\u00f6tigten Konstanten und Typen \u00fcberhaupt finden.<\/p>\n Zum Artikel …<\/a><\/p>\n Im Beitrag \u00bbAPI-Deklarationen finden und speichern\u00ab haben wir gezeigt, wie Sie alle API-Deklarationen eines VBA-Projekts finden und sowohl die Daten der API-Funktion als auch die der Parameter in zwei Tabellen speichern. Zu API-Deklarationen geh\u00f6ren jedoch auch einige Konstanten und Typen, die beim Aufruf der API-Funktionen verwendet werden oder als Parameter der Funktionen dienen. Im Sinne des Schaffens einer M\u00f6glichkeit zum Migrieren von API-Deklarationen von 32-Bit zu 64-Bit wollen wir auch diese Elemente zun\u00e4chst in entsprechenden Tabellen speichern, um diese dann per Code anzupassen und in der 64-Bit-Version auszugeben.<\/p>\n Zum Artikel …<\/a><\/p>\n Wenn Sie eine gr\u00f6\u00dfere Anwendung pflegen m\u00fcssen, kann es hin und wieder sinnvoll sein, nicht mehr verwendete Routinen rauszuwerfen oder zumindest auszukommentieren. Das ist gerade praktisch, wenn Sie die API-Funktionen von 32-Bit auf 64-Bit umstellen wollen: Um hier Arbeit zu sparen, k\u00f6nnen Sie erst einmal alle API-Funktionen auskommentieren, die nicht mehr ben\u00f6tigt werden. Um verwaisten Routinen zu finden, gibt es verschiedene M\u00f6glichkeiten: Sie k\u00f6nnen dies durch Auskommentieren und Testen von Hand erledigen, ein Tool wie MZ-Tools einsetzen oder auch ein selbst programmiertes Tool. Letzteres k\u00f6nnte der entsprechenden Funktion von MZ-Tools noch einen draufsetzen und auch die Aufrufe aus den Eigenschaften von Formularsteuerelementen oder Abfragen ermitteln.<\/p>\n Zum Artikel …<\/a><\/p>\n Die Verbindung von Access zum SQL Server erfolgt in der Regel \u00fcber ODBC. Hierzu wird vorab eine ODBC-Datenquelle erstellt und unter einem Data Source Name \u2013 kurz DSN \u2013 gespeichert. F\u00fcr den Datenzugriff liefert die ODBC-Datenquelle die Bezeichnung des SQL Servers und den Namen der Datenbank. Der Anmeldename und das Kennwort hingegen kommen direkt aus der Access-Applikation. Dabei sind die in Access gespeicherten Anmeldedaten ein nicht zu untersch\u00e4tzendes Sicherheitsrisiko. Dieser Beitrag beschreibt die Risiken und zeigt Ihnen Mittel und Wege, wie Sie diese vermeiden k\u00f6nnen.\u00a0<\/p>\n Zum Artikel …<\/a><\/p>\n Auch eine Access-Applikation muss irgendwann den User erreichen, und je einfacher wir es diesem machen, umso besser f\u00fcr uns. Zu diesem Zweck verwenden Entwickler seit vielen Jahren sogenannte Installations- oder Setup-Programme. Das kostenlose InnoSetup ist ein solches, das \u00fcber den in Access bereits enthaltenen „Verpackungs- und Weitergabeassistenten\u201d weit hinaus geht. In diesem Artikel erfahren Sie die Grundlagen, weitere Artikel befassen sich mit der Umsetzung und m\u00f6glichen Erweiterungen.<\/p>\nSelektionen kombinieren<\/h3>\n
API-Funktionen finden und speichern<\/h3>\n
API-Typen und -Konstanten finden und speichern<\/h3>\n
Verwaiste API-Funktionen finden<\/h3>\n
SQL Server-Security, Teil 6: ODBC-Datenquellen und gespeicherte Kennw\u00f6rter<\/h3>\n
Setup f\u00fcr Access-Anwendungen<\/h3>\n