Outlook-Objekte in Access speichern

Kontakte, E-Mails, Termine und Aufgaben – den Abgleich all dieser Objekte zwischen Access und Outlook haben Sie als fleißiger Leser bereits kennen gelernt. Falls nicht, empfiehlt sich ein Blick auf die im Onlinearchiv gespeicherten Beiträge mit den Shortlinks 290 (E-Mails), 439 (Termine), 113 und 129 (Kontakte) sowie 498 (Aufgaben).

Diese Artikel beschreiben in der Regel, wie Sie die jeweiligen Objekte von Access nach Outlook und zurück bekommen – allerdings immer von Access aus gesteuert. Dementsprechend sollte es auch kein Problem sein, in Access eine Funktion zu implementieren, die neu angelegte oder geänderte Elemente direkt nach dem Anlegen oder ändern mit Outlook synchronisiert.

Dies funktioniert natürlich auch andersherum: Sie können ohne größeren Aufwand dafür sorgen, dass Outlook, wenn ein Benutzer ein neues Element wie etwa einen Kontakt anlegt, direkt den passenden in einer Datenbank gespeicherten Eintrag ändert.

Beispielhaft

Um die Beispiele nachvollziehen zu können, kopieren Sie einfach den Inhalt der Datei ThisOutlookSession.cls in die gleichnamige Klasse im Outlook-VBA-Editor und passen die darin enthaltenen Pfadangaben an.

Outlook-Ereignisse

Zum Automatisieren von Outlook selbst bedarf es natürlich erstens eines kleinen Blickes in das Objektmodell und dort vor allem auf die Ereignisse, die beim Anlegen oder ändern von Outlook-Elementen ausgelöst werden – und es muss klar sein, dass Sie die notwendigen Prozeduren natürlich innerhalb von Outlook und nicht in einer Access-Anwendung anlegen. Der Ort für das Deklarieren ereignis-sensitiver Objekte in Outlook ist schnell gefunden: Es handelt sich dabei um ein standardmäßig vorhandenes Klassenmodul namens ThisOutlookSession. Die Ereignisprozeduren des Application-Objekts, also von Outlook selbst, werden hier, soweit vorhanden, automatisch ausgelöst. Das erkennen Sie ganz leicht, wenn Sie zum VBA-Editor wechseln (von Outlook aus am schnellsten per Strg + F11), dort das Modul ThisOutlookSession öffnen und im linken Kombinationsfeld des Codefensters Application auswählen. Das rechte Kombinationsfeld liefert dann alle möglichen Ereignisse. Die leere Ereignisprozedur, die das öffnen einer Outlook-Instanz auslöst, sieht dann etwa so aus:

Private Sub Application_Startup()
End Sub

Ab jetzt kommt es darauf an, was Sie vorhaben: Soll eine Mail, ein Kontakt, ein Termin oder eine Aufgabe direkt nach dem Anlegen in einer Access-Tabelle gespeichert werden Oder muss dies auch bei änderungen geschehen

Aufgaben nach Access

Werfen Sie zunächst einen Blick auf das Anlegen einer neuen Aufgabe in Outlook. Diese soll direkt nach dem Erzeugen in eine Access-Tabelle wie die aus dem Beitrag Outlook-Aufgaben (Shortlink 498) exportiert werden.

Was für ein Ereignis benötigen Sie hier Eines, das in Zusammenhang mit dem neuen Element (hier einer Aufgabe) selbst ausgelöst wird Nein! Das neue Element existiert ja zu dem Zeitpunkt, an dem Sie die Ereigniseigenschaft schreiben, die ein neues Aufgaben-Element nach Access schieben soll, noch gar nicht. Ein „New“- oder „Add“-Ereignis steht auch so gut wie nie für ein einzelnes Objekt zur Verfügung, sondern meist für die Auflistung, die das zu erzeugende Element einmal aufnehmen wird. Und das ist in diesem Falle die Items-Auflistung des Aufgaben-Ordners.

Damit Sie die Ereignisse eines Elements durch entsprechende Ereignisprozeduren abfangen können, müssen Sie dieses – wenn es nicht wie das Application-Element bereits vorhanden ist – zunächst deklarieren und instanzieren, wobei Sie beim Deklarieren das Schlüsselwort WithEvents verwenden. Die folgende Anweisung deklariert zunächst einen handelsüblichen Outlook-Ordner:

Dim WithEvents objItems As Outlook.Items

Damit dieses Objekt explizit beim Anlegen eines bestimmten Outlook-Elements Ereignisse auslöst, instanzieren Sie es mit dem entsprechenden Typ, hier der Items-Auflistung des Aufgaben-Ordners:

Private Sub Application_Startup()
 Set objItems = Application.Session.GetDefaultFolder(olFolderTasks).Items
End Sub

Im Gegensatz zum Verwenden einer Outlook-Instanz von Access aus benutzen Sie hier nicht die GetDefaultFolder-Methode von Application.GetNamespace(„MAPI“), sondern von Application.Session, was einen expliziten Zugriff auf die in der aktuellen Sitzung erzeugten und bearbeiteten Objekte zulässt.

Wenn Sie nun einen Blick auf die Ereignisse der oben deklarierten Auflistung objItems werfen, finden Sie auch direkt etwas Passendes (siehe Bild 1).

Für einen Test verwenden Sie zunächst das ItemAdd-Ereignis. Folgende Implementierung zeigt in einem Meldungsfenster den Betreff und den Inhalt einer frisch angelegten Aufgabe an, wobei der Parameter Item einen Verweis auf das passende Element liefert:

Private Sub objItems_ItemAdd(ByVal Item As _
 Object)
   Dim objTaskItem As Outlook.TaskItem
   Set objTaskItem = Item
   With objTaskItem
     MsgBox .Subject & " " & .Body
   End With
End Sub

Um diese Routine zu testen, schließen Sie Outlook nach der Eingabe, bestätigen das Speichern des Moduls VbaProjekt.OTM und öffnen Outlook erneut. Bereits beim öffnen instanziert Outlook die festgelegte Aufgaben-Auflistung und ist von nun an bereit, auf neu angelegte Elemente mit der oben beschriebenen Routine zu reagieren. Beachten Sie, dass Outlook die Ereignisse immer erst beim Speichern des neu angelegten oder geänderten Elements auslöst.

Die Methode ItemChange können Sie genauso wie ItemAdd verwenden, um geänderte Elemente mit der Datenbank zu synchronisieren.

Allein die ItemRemove-Methode vermag ihre Aufgabe nicht recht zu lösen – das geht allein aus ihrer Deklaration hervor. Die Parameterliste ist nämlich leer, das heißt, dass die Routine keine Informationen über das gelöschte Element liefert, sondern allein über den Löschvorgang selbst informiert:

Private Sub objItems_ItemRemove()
End Sub

Löschsynchronisation

Um ein innerhalb von Outlook gelöschtes Element auch in der passenden Access-Tabelle zu löschen, müssen Sie zu anderen Mitteln greifen. Die richtige Methode namens Delete liefert nämlich das TaskItem-Objekt, für andere Elemente gibt es Objekte wie MailItem (E-Mail), ContactItem (Kontakt) oder AppointmentItem (Termine).

Also deklarieren Sie zunächst im gleichen Modul eine Objektvariable mit Ereignisbehandlung zum Verweis auf das zu löschende Element:

Dim WithEvents objTaskItem As Outlook.TaskItem

Für andere Elemente deklarieren Sie dieses als eines der oben genannten Objekte. Nun müssen Sie allerdings noch einen Weg finden, einen Verweis auf das zu löschende Objekt zu erstellen. Was passiert den überhaupt im Verlauf eines Löschvorgangs Zunächst markiert man das zu löschende Objekt und initialisiert dann den Löschvorgang selbst, indem man beispielsweise auf die Entf-Taste klickt oder den Löschen-Eintrag aus dem Kontextmenü auswählt.

Interessant ist die Auswahl des zu löschenden Objekts: Forschen wir also nach einem Ereignis, das beim Auswählen eines Outlook-Elements ausgelöst wird, und fangen ganz oben an: bei den Ereignissen des Application-Objekts. Mmmh … viel versprechend sieht das nicht aus; vielleicht hilft Application_ItemLoad weiter.

Um dies zu testen, legen Sie einfach die passende Ereignisprozedur an und fügen eine simple Anweisung wie folgt hinzu:

Private Sub Application_ItemLoad(ByVal _
 Item As Object)
   MsgBox "ItemLoad aufgerufen"
End Sub

Klicken Sie dann in eine der Listen (beispielsweise E-Mails, Kontakte etc.) und seien Sie erfreut: Die Auswahl eines der Einträge löst dieses Ereignis aus. Das ist perfekt, Sie müssen also nur noch prüfen, ob es sich beim ausgewählten Element um den richtigen Typ handelt (immerhin wollen wir hier erstmal nur Aufgaben behandeln) und diesen gegebenenfalls der Objektvariablen objTaskItem zuweisen:

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo