Office: (Office 2007) Löschen von Termineinträgen in Outlook

Einwurf:

Mit geeigneten Abläufen und Maßnahmen könnte man es sich viel einfacher machen. Wie verschwinden denn Termine aus der Accesstabelle?

Wenn man sich beim Löschen die EntryID "merkt", könnte man direkt in den Outlookterminen das entsprechende Item identifizieren und entfernen.

Das ist im Vergleich so, als wenn man an die Stecknadel, die man in den Heuhaufen wirft, erst einen Faden anbringt, mit dem man die Nadel wiederfinden kann.
Den meisten ist es aber ein Bedürfnis, erst etwas zu tun, um hinterher ermitteln zu müssen, was sie denn getan haben, und das meist mit beschränkten Mitteln und Fähigkeiten. Also: Rein mit der Nadel in den Heuhaufen, und dann mit mehr oder weniger Beleuchtung suchen.
Was würde denn jener tun, der ökonomisch mit seiner Zeit umgehen will?

 

Hallo Frank!

Die EntryID dient zur Identifizierung eines Outlookeintrags.
Sie sieht zB. aus wie folgt:
Eintrag.EntryID:0000000058BA313976783541A5971750BC69753464363100
und ist in Outlook eindeutig.

Diese musst Du in Deiner Tabelle tblTermine irgendwo gespeichert haben, sonst wirst
Du die Daten von Access nicht mit jenen von Outlook abgleichen können.
Fehlt sie, so besteht ein massiver Fehler beim Aufbau Deiner Anwendung
Daher ist die Zeile mit DCount so wie sie geschrieben steht logisch richtig.

EntryID in der Tabelle tblTermine und EntryID im Outlook-Kalender wären die Schlüssel.
Der Autowert TerminID in der Tabelle tblTermine definiert den Datensatz in Access aber nicht in Outlook.

Du hast doch mittels Access die Daten in Outlook aktualisiert oder neu eingetragen.
Wie hast Du Dir vorgestellt, einen Bezug von Access zu Outlook herzustellen?

Übrigens:
„Public Property Get“ gehört in ein Klassenmodul und ist in einem Standardmodul fehl am Platz.

Oje, oje. Da gibt es noch sehr viel Arbeit für Dich.

Wolfgang

 

Woher übernimmt man eine solche Überzeugung?
CurrentDbC von Michael Kaplan ist ein häufig anzutreffendes Beispiel für eine Widerlegung der Behauptung.

 

Hallo Eberhard!

Hauptsache, Du kannst eine Aussage auseinandernehmen.

Ich verwende Properties **nur** in Klassenmodulen und nicht in allg. Modulen.
Was mMn für einen Anfänger auch ratsam erscheint.
Daß Du weißt, daß es möglicherweise auch anders genutzt werden kann ist schön für Dich, kümmert mich aber überhaupt nicht.

Einige hier müssen sich halt wichtig machen und alle anderen als Idioten hinstellen.

Danke für die überflüssige Belehrung.

Wolfgang

 

Auf meine Rückfrage fallen Dir ja viele Interpretationen ein, eine plausible Antwort kann ich da aber nicht ausmachen.

Das ist ganz sicher kein einseitiger Prozess ...

 

Hallo Eberhard!

Etwas Bescheidenheit täte Dir sehr gut.
Du bist wirklich nicht der Größte, für den Du Dich hältst.
Und das letzte Wort mußt Du wohl auch immer haben.
Wirkt ziemlich peinlich.

Wolfgang

 

Eine Rückfrage zu stellen, um am Wissen eines anderen teilhaben zu können, würde ich nicht als Unbescheidenheit werten. Ein "Ich mache das so" und ein "alles andere interessiert mich nicht" ist aber kaum eine werthaltige fachliche Antwort. Kommt da noch mehr?

Dann die fachliche Ebene im Laufschritt zu verlassen und sich in persönlichen Anfeindungen zu ergehen zeugt von einem Charakter, der im allgemeinen wenig geschätzt wird. Die Führungskraft hält sich für ... ? Wo liegt die Peinlichkeit?

 

\@Schumi_64:
Mit den gemerkten EntryID lt. #16 könnte es etwa so gehen:
Code:

Dabei ist GetMAPINamespace eine Deiner Properties von oben (hier durchaus gut einsetzbar), und AnyEntryID steht für jeweils eine der EntryID's der gelöschten Datensätze.

Einfacher und direkter wird es wohl nicht gehen, allerdings müsstest Du beim Löschen von Datensätzen eben wie angemerkt vor dem Löschvorgang diese ID's irgendwie speichern, z.B. in einer Extratabelle.

Beachten: Es gibt hier keine Begrenzung auf Termine. Gleichlautend könnten Aufgaben, Kontakte, Mails gelöscht werden.

 

Hallo Wolfgang,

Du hast Recht. Ich habe da etwas falsch verstanden. In der Beschreibung zu dem Exportcode habe ich folgendes gefunden. "Die Routine durchläuft einfach alle Datensätze der Tabelle tblTermine und macht sich zu Nutze, dass man in Outlook sogar nach dem Inhalt von benutzerdefinierten Feldern suchen kann (bei einigen eingebauten Feldern wie etwa EntryID funktioniert das nicht). In diesem Fall versucht die Routine zunächst, einen Eintrag aus dem Kalender-Ordner zu finden, dessen benutzerdefinierte Eigenschaft TerminID den Wert des Primärschlüssels des aktuellen Datensatzes enthält. Ist das nicht der Fall, legt sie einen neuen Termin mit den in der Tabelle enthaltenen Daten an und erzeugt auch die benutzerdefinierte Eigenschaft TerminID mit dem passenden Primärschlüsselwert. Ist der Termin bereits vorhanden, prüft die Routine, ob sich das Änderungsdatum der beiden unterscheidet. Falls ja, überträgt sie die Daten aus der Access-Tabelle in den Outlook-Termin." Er muss also den Wert nicht in EntryID suchen, sondern in einem benutzerdefinierten Feld Namens TerminID des Kalenders. Das war natürlich ein grober Fehler von meiner Seite. Sorry. Zu deiner Äußerung ich habe noch Nachholbedarf gebe ich dir absolut Recht. Ich habe mir dazu auch schon ein Buch rausgesucht. Vielleicht kennt jemand hier im Forum ja das Buch.
http://www.amazon.de/Access-2010-Gru...ccess+2010+vba
Ist das für Anfänger geeignet?
Von dem Autor stammt übrigens auch der Code zum Im- und Export.

Ich wünsche übrigens allen hier im Forum noch ein gesundes neues Jahr, viele gute neue Ideen und weniger Beschimpfungen wie hier im Thread vorher gesehen. Ich denke konstruktive Kritik sieht anders aus.

Frank

 

Hallo ebs17,

danke für deine Antwort. Das Problem ist hierbei, das die Termine in einer Tabelle verwaltet und bearbeitet werden. Es kommt also vor, das mehrere Termine gleichzeitig verändert bzw. gelöscht werden. Die Aktualisierung des Outlookkalenders soll aber nicht immer sofort erfolgen. Das Arbeiten mit der Accessanwendung erfolgt auf verschiedenen PC´s. Die Aktualisierung der Outlookdaten dagegen nur auf einem davon. Von dort aus erfolgt auch die Synchronisierung des Kalenders auf dem Handy für die Montage. Deshalb würde ich die Aktualisierung (Löschung) der nicht mehr benötigten Datensätze in der angedachten Form bevorzugen.
Frank

 

Wenn die DB-Anwendung auf mehreren Rechnern läuft, wie führst Du dann deren Änderungen auf diesen einen Rechner zusammen, damit dort ein sachlich richtiger Abgleich mit Outlook erfolgen kann?

 

Die BackEnd befindet sich auf einem USB- Stick, welcher auf allen Rechnern immer als Netzlaufwerk Z:/ verknüpft wird. So ist die BackEnd immer auf dem aktuellen Stand. Es gibt übrigens nur einen Bearbeiter. Dieser arbeitet aber je nach Arbeitsaufgabe an verschiedenen Rechnern. (Büro, Lager, Montage/ Unterwegs) Teilweise findet die Bearbeitung auch nur mit einer Runtime statt.
Frank

 

Dann bleibt das Ganze übersichtlich.

Vorab noch einmal: Meine Antwort bezieht sich auf das Löschen von Outlookterminen, die in Access erfasst und dort gelöscht wurden.

Wenn man die EntryID, die ein Outlook-Item eindeutig identifiziert (wenn da nicht problematische Verschiebungen stattfinden) schon in der Accesstabelle erfasst ist, kann man die doch unmittelbar nutzen. Die gezeigte Methode GetItemFromID ermöglicht den unmittelbaren Zugriff.
Das erscheint mir effizienter als in Schleife alle Termine in Outlook zu durchlaufen (womöglich gibt es sehr viele) und dann ein DCount-Dauerfeuer auf eine möglicherweise auch große Tabelle loszulassen.

Problem ist nur: In einem Datensatz, den man löscht, braucht man keine Informationen zum Löschvorgang ablegen, weil er ja verschwindet.
Daher müsste man diese Löschinformation extern ablegen, und zwar unmittelbar vor dem Löschvorgang. Das kann man über ein Formular steuern, wenn von da aus der Vorgang eingeleitet wird. Bei Aktionsabfragen weiß man sicher auch, was man tut und kann entsprechend reagieren. Änderungen in der Tabelle wären dann aber streng verboten, es sei denn, hier könnte man die in Acc2010 eingeführten DataMacros nutzen.
Das externe Ablegen kann auch in einer Backend-Tabelle erfolgen, da kann man auch Vorgänge sammeln.

 

Hallo ebs17,
grundsätzlich hast du sicherlich Recht. Leider habe ich nicht die Möglichkeit die Backend zu überwachen, das keiner hinten herum etwas verändert. Gerade Excel- Tabellen verleiten ja zum rumfummeln. Des weiteren ist die EntryID von Outlook nur solange gültig, wie keiner die Datensätze verschiebt. Auch das kann man leider nicht verhindern. Deswegen gefällt mir die Variante von Wolfgang eigentlich sehr gut. Zum Thema Datenmenge. Ich denke es handelt sich etwa um ca. 300 Termineinträge. Nun habe ich nicht die Erfahrung, wie lange da die Bearbeitungszeit mit der dcount- Methode ist und ob man das schon als Dauerfeuer bezeichnen kann. Es kommt noch dazu, das momentan die EntryID nicht in meiner Tabelle enthalten ist, sondern nur der in meiner Tabelle erzeugte Autowert TerminID, welcher als benutzerdefinierte Eigenschaft an dem jeweiligen Termin in Outlook angefügt ist. Ich müsste also den gesamten Code für den Im- und Export auch noch ändern. Als VBA- Anfänger ist mir das zu kompliziert. Vielleicht funktioniert das ja doch mit der Methode von Wolfgang.
Frank

 

Von der ursprünglichen Aufgabenstellung ist nicht mehr viel übrig, und natürlich kannst Du alles ausprobieren, was Dir in den Sinn kommt oder was vorgeschlagen wird.

DCount-Dauerfeuer beginnt in meinem Verständnis bereits mit dem zweiten DCount auf die gleiche Tabelle. Die kleine Anweisung hat immerhin in sich eine komplette Abfrage, als Datenbänkler führt man aber besser eine (1 in Zahlen) richtige Abfrage aus als ...zig einzelne Abfragen.

Bei der jetzigen unorganisierten Situation wäre es mein Bestreben,
- den Terminordner komplett auszulesen und wesentliche Inhalte in eine temporäre Access-Tabelle zu schreiben (inkl. der EntryID),
- dann die Temp-Tabelle per DDL nachzuindizieren
- und somit per SQL Temp-Tabelle und Accesstabelle vergleichen zu können (der Schlüssel TerminID ist wohl verfügbar), also für alle Datensätze jeweils gleichzeitig.

Der Vergleich würde dann in drei Abfragen bestehen:
1) Termine aus Access in Outlook nicht vorhanden (Inkonsistenzprüfung) => alle neu anlegen
2) Termine aus Outlook in Access nicht vorhanden => löschen über Zugriff auf EntryID
3) Termine gibt es in beiden Tabellen, unterscheiden sich aber in einem wesentlichen Wert => aktualisieren über Zugriff auf EntryID

Ich unterstelle hier Aktualisierung einseitig von Access aus auf Outlook.

Ja, durchaus. Spielen da welche eine Rolle?