Office: (Office 2013) Access

Nebenbei:

Ich sah mal eine Lösung, wo das Accessformular halbtransparent gesetzt wurde, damit man das darunter liegende Excelblatt im Auge haben konnte, so als Ersatz für jene, die nicht mit Superbreitbildschirmen arbeiten und alles nebeneinander legen können.

 

Hallo Günter,

der Text verwirrt mich leider etwas.
Was genau existiert in Access bevor die Aufgabe in Outlook erstellt wird.
Wie wird die Aufgabe erstellt.
Und wie geht es dann genau weiter?


diese Codestelle würde ich ändern:

If OApp = "Nothing" Then

dieser Zustand wird nie eintreffen.

entweder so:

If OApp Is Nothing Then

oder so

If TypeName(OApp) = "Nothing" Then

LG Markus

 

Das ist in der Tat ein Problem, wie oft bei Interprozesskommunikation mit Anwendungen, die keine spezifische Schnittstelle für den speziellen Anwendungsfall bereitstellen.

Die Lösung von @markusxy entsprechenden Code in Outlook zu hinterlegen, gefällt mit persönlich nicht. Ich habe bei meinen Benutzern üblicherweise nicht die Möglichkeit VBA in Outlook zu definieren.

Ich würde von Access aus eine ObjektReferenz auf Outlook setzen. Über diese dann ein AppoinmentItem erstellen und mir in Access dessen Objektreferenz sowie die ID der zugehörigen Entity aus der DB merken und das Save-Event des AppoinmentItems behandeln. Im Save-Event dann die EntryID des Appointments und evtl. weitere Daten in der DB abspeichern.
Mit der EntryID hat man dann eine eindeutige, dauerhafte Referenz auf das AppoinmentItem, die für zukünftige Synchronisierungen genutzt werden kann.

Natürlich kann dieser Prozess auch schief gehen. Z.B. wenn der Benutzer in Outlook erstmal das Geburtstagsessen seiner Großmutter einträgt und danach in einem neuen Appoinment den Geschäftstermin. Auch kann sich unter, eher unwahrscheinlichen, Umständen die EntryId des AppoinmentItems irgendwann ändern.

 

Leider nicht ganz. Wenn der Termin verschoben wird (bspw. in einen anderen Terminordner), bekommt er eine neue EntryID, und die alte Referenz ist für die Katz. Wenn man nun das Outlook von den Nutzern nicht steuern kann bzw. nicht mal weiß, was da überhaupt stattfindet, ist das ein Problem.

Zweifellos ist die EntryID aber die Möglichkeit, auf ein Item gezielt per Direktsuche zuzugreifen, statt im ganzen Ordner Schleifen laufen zu müssen. Wenn man mal eine Datenbanktabelle und einen größeren Kontakteordner synchronisieren müsste, weiß man das zu schätzen.

 

Das ist ein interessanter Einwand. - Interessant deshalb, weil ich eigentlich behauptet hätte, dass er nicht besonders kritisch ist. (Genau dies meinte ich mit "unwahrscheinlichen Umständen".)

Laut Dokumentation der EntryId ändert sich diese nur, wenn ein Objekt in einem anderen Informationsspeicher, also ein anderes Exchange-Postfach oder eine andere .PST-Datei) verschoben wird.
Diesen Fall halte ich für weniger wahrscheinlich und man hat dann evtl. auch noch andere, gravierendere Probleme mit Zugriffsrechten und Erreichbarkeit des Postfachs/PST-Files. Daher ist das m.E. nicht so kritisch.

Ich habe das jedoch auf deine Anmerkung hin eben mal noch überprüft. - Für Outlook Items, die in einer PST-Datei gespeichert sind, ist das Verhalten genau so wie dokumentiert, aber bei Outlook Items, die in einem Exchange Postfach liegen, ist es tatsächlich, anders als dokumentiert, so, dass diese auch dann schon eine neue EntryId bekommen, auch wenn man sie nur in einen anderen Ordner innerhalb desselben Postfachs verschiebt.
(Getestet mit Outlook 2013 und Exchange Server 2007)

Ich bin sehr sicher, dass das Verhalten bei älteren Versionen von Exchange noch der Dokumentation entsprochen hat. - Ich habe nämliche mehrere Anwendungen, die genau diesen Mechanismus nutzen... :-(

 

Noch ein kleiner Input.
Das Hick Hack bezüglich Details finde ich entbehrlich, aber gehört nun mal zur Kultur eines Forums.

Ich weiß nicht ob Sync zwischen Access, Outlook und Handy zu MustHave oder NiceToHave gehört.

Ich finde, gerade in diesem Fall geht es um die Frage des User Interfaces.
Also nachsehen in Outlook und anlegen in Access? Anlegen direkt in Outlook? Beides? Wie werden Änderungen eingepflegt? Outlook oder Access? Beides?
Wie schaut es aus, wenn die Dame unterwegs ist. Sprich Terminänderungen, Absagen oder völlig neue Termine. Was dann?
Da wird das Handling mit dem Sync schon etwas anspruchsvoller.
Dann bleibt natürlich die Frage wie dausicher programmiert werden soll?

Mein Interesse rührt auch daher, dass ich in Bälde selbst ein ähnliche Aufgabe habe. Nur keine Physio sondern Psycho. Die sind auch sehr zäh in Sachen Sortware.
Gruß Markus.

 

Also ich habe das so gelöst.

Tabellen wie folgt: Patient =1:n=> Fall =1:n> Termin.

Wird nun im Forumar ein neuer Fall angelegt wird der Benutzer aufgefordert die Anzahl der Termin sowie den Typ (Physiotherapie, Massage, Hausbesuch) auszuwählen, daraufhin wird in meiner Fall_Tabelle die entsprechende Anzahl der Termine angelegt. Daraufhin erstelle ich von Access Aufgaben in Outlook, mit einem spezifischen Namen: Mustermann_2Fall_Therapie und der Fall ID im Billing. Diese Aufgaben können nun in den Kalender gezogen werden.

Bezüglich meiner Frage Klassenobjekte und Property Get Verknüpfung, hat hier dazu jemand eine Meinung ?

lGünter

 

Wenn du sicher sein kannst, dass die BillingInformation niemals anderweitig verwendet wird, ist das wahrscheinlich ok.
Ich würde noch testen, wie sich die Performance verhält, falls du mal einen Termin oder eine Aufgabe anhand der FallId aus Access suchen musst.

Den Ansatz deine clsOutlook über eine Property in einem Modul projektweit zur Verfügung zu stellen, finde ich gut. Würde ich genauso machen.

Deine Properties GetMAPINamespace und GetTaskFolder hätte ich als Property-Methoden der clsOutlook implementiert. Dann ist die Outlook-Logik innerhalb der Klasse gekapselt. - Das ist aber ein Thema der Gliederung deines Programms und weniger der funktionalen Logik.

 

Hätte ich gewußt, dass du vorher eine Aufgabe anlegst, hätte ich einen ganz anderen Vorschlag gemacht.

Bei Oapp wird der Listener des Quit Events ja automatisch initialisiert. Wenn Du das bei allen Aufgaben brauchst, ist das ja o.k.
Wenn man da flexibel sein will ist es einfacher eine Funktion in einem öffentlichen Modul zu verwenden.
LG Markus