Office: (Office 2013) Access

OK, das ist der Trick mit dem MS-Forms-Objektframe. Damit kriegt man das Control auf ein Access Form.
Eine andere Frage ist halt, wie stabil das dann tatsächlich funktioniert.
Wenn Microsoft davon in der Dokumentation ausdrücklich als "unsupported" abrät, sollte man das eingehend testen und auch nicht völlig überrascht sein, wenn es nach irgendeinem Update dann auf einmal gar nicht mehr funktioniert.

 

allo

@Sonic8#12: Das wars, so funktionert es, danke. Deinen Artikel werde ich mir zu Gemüte ziehen.

@ beide: Meine Frau hat eine Physiotherapie Praxis und ich prorgrammiere für sie die Datenbank, inkl. Patientenverwaltung, Terminvergabe mit automatisierter Rechnungslegung und Buchhaltung. Jeder Patient hat im Schnitt 6 Termine. Diese werden in Outlook eingetragen und über die Billing Information wird die Fall_Eigen_ID ausgelesen. Ich mache es über Outlook, da die Kalenderfunktionn sehr übersichtlich ist und sie diesen auch mit ihrem Smartphone synchronisieren kann.
Da meine Frau alles was mit Computern zu tun hat scheut, wie der Teufel das Weihwasser, soll alles von der Access Datenbank ausgeführt werden, eben auch Outlook Start, wenn sie nur die Kalenderfunktion benötigt. Wie Sonic richtig vermutet hat, ist das Schließen von Outlook der Trigger für die Termin Synchronisation.
Outlook immer offen zu lassen wäre natürlich ein Option und dann einen Button im Menüband heranziehen, um Outlook zu minimieren und die Termin-Sync durchzuführen.

Die Terminsynchronisation habe ich mir von Andre Minhorst abgeguckt und etwas abgewandelt: www.access-im-unternehmen.de

LGünter

 

Da hier auch von Konzeptfragen gesprochen wurde:
Bei einer seit 13 Jahren laufenden Kundenverwaltung für einen Finanzdienstleister läuft es so, dass Eingaben zu Kunden komplett in der Datenbank erfolgen und dann bei Bedarf gewünschte Termine und Kontakte einzeln oder gruppenweise nach Outlook übergeben werden.
Termine werden ja automatisch schon aus Kundenverträgen (z.B. Vertragsabläufe) "erzeugt" wie auch aus Aufgaben aus Kundenbetreuung.

Outlook ist dann nicht nur ein zusätzliches Arbeitsmittel, sondern vor allem die Schnittstelle nach außen für mobile Geräte (früher PDA, heute Smartphone & Co.). Solche Geräte wechseln sehr oft und sind sehr unterschiedlich (bei Selbstausrüstern um so mehr), aber eine Synchronisierungsmöglichkeit mit Outlook ist da Muss-Standard.
Bei der DB-Lösung würde ich mich nicht mit mit solchen Hardwarewechseln und entsprechenden Anpassungen beschäftigen wollen.

 

\@Eberhard
Ich seh es auch als die bessere Lösung, das Kalenderinterface in Access zu halten, und die Daten an Outlook zu übertragen.
Zumal ich in Access den Kalender wesentlich besser gestalten kann, was die Abstimmung mit dem Anwender anbelangt.
Für Sync ist für mich MS Exchange die erste Wahl.
Allerdings kenne ich mich da zugegebenermaßen nicht sonderlich gut aus.

 

In dem Outlook Kalender sind sowohl berufliche als auch private Termine eingetragen, dass wenn ein Patient anruft sie auf einen Blick sieht ob und wann noh Kapaziäten frei sind. Würde ich das Kalender item in Access nutzen, welches meines Wissens by the way nicht annähernd die Funktionlität von Outlook aufweißt, müßte ich alle, auch private Termine in Access eintragen um ihr die selbe Funktionalität zu bieten. Ich möchte jedoch in der Datenbank nur berufliche Belange abbilden.

@ Sonic: VBA - Handling events... => gefällt mir sehr gut und ich werde es versuchen umzusetzen.

Eine kleine Anmerkung zu Private Sub Command0_Click(), duch folgende Zeile, wird Outlook angezeigt und gleich zu dem relevanten Ordner gewechselt

PHP:

         m_outlApp.Session.GetDefaultFolder(olFolderContacts).Display


 

Ich denke es lässt sich nicht pauschal entscheiden, was das bessere Vorgehen für die Terminerstellung ist. Wenn, wie in deinem Fall, Termine sehr strikt auf Basis des Datenbestandes der DB erstellt werden, ist es natürlich vorzuziehen, die Termine direkt dort zu erstellen und nur nach Outlook zu exportieren.

Wenn aber Outlook auch als Werkzeug bei der eigentlichen Terminfindung genutzt wird (Blick in den Kalender (mit nicht-DB-Terminen), Besprechungsanfrage per Mail, Frei-/Gebucht-Abfrage von Kollegen, etc.) , dann macht es aus meiner Sicht mehr Sinn, den Termin in Outlook zu erstellen (und damit meine ich vor allem die User-Aktion), und dann nur den fertigen Termin wieder nach Access zu importieren.

 

Hallo Günter
Ich hab kurz mit den Events gespielt.
Es ist möglich mit den Items Ereignissen (ItemAdd und ItemChange) das Termin Objekt an Access zu übergeben und weiter zu verarbeiten.

Beispiel:
Variable deklarieren
Private WithEvents wKal As Items

Code:

Code:

genauso kann man mit Change verfahren.
Fürs Löschen würde ich zuerst Application_ItemLoad einen Zeiger auf das Termin Objekt legen und dann mit dem Ereignis AppointmentItem.BeforeDelete wiederum das zu löschende Objekt an Access übergeben.

Lg Markus

 

Dort sehe ich aber Probleme, solche Termine den richtigen Personen zuzuordnen - oder wie würde man eine ID-Vorbelegung mit Outlookmitteln realisieren?

 

Eberhard, danke für die Frage, die hat mir grade eine geniale Lösung für eine meiner Anwendungen gezeigt.
Wenn man den Termin unbedingt über Outlook erstellen will, kann man das ja auch über einen Dialog klären, welcher in Access hinterlegt ist und von Outlook aus aufgerufen wird. Diesen Lösungsweg habe ich bisher eher verworfen, entdecke aber soeben sein geniales Potential für andere Aufgabenstellungen.

Hier z.B. übergeben ich die in Access ausgewählte Adresse-ID an Outlook zurück.

Code:

Access öffnet ein Formular und ermöglicht die Auswahl des Klienten via Combobox oder was auch immer und übergibt die ausgewählte Info, wieder an Outlook.
Im Fall von Günter ist das dann die Billinginfo, welche in Access verwendet wird.
LG Markus

 

\@Markus: Das wäre dann also ein Eingabe-Hin-und-Her?

Was ich mich immer gefragt habe: Wo hinterlegt man in einem Outlook-Item eine solche bezeichnende ID, idealerweise in einem vorhandenen Standardfeld, wenn man bei externen Nutzern und deren Installationen nicht spezifische Eigenschaften erzeugen kann (oder sollte)?

 

Das lässt sich durch die Verwendung entsprechender Kategorien o.ä. abbilden. Handhabe ich persönlich genau so: Meine dienstlichen Termine erzeuge und verwalte ich (aussschlielich) in Access, und aktualisiere sie von da nach Outlook (primär der Syncronisation mit Handy's u.ä. wegen, nebenher um mir die aufwendige optische Nachbildung diverser Kalenderansichten in Access zu ersparen.)

Die Trennung von den "nicht dienstlichen" Terminen, die von Eingriffen per Access verschont bleiben sollen, funktioniert bestens per Zuweisung entsprechender Kategorie(n).

Das nur als Gedankenanstoss.

 

Ganz richtig, oder einfach ein kreativer Weg, neben anderen Möglichkeiten.
Ich würde auch eher den Weg über Access gehen, aber in diesem Fall ist es etwas anders.
Bei Access würde ich den Vorteil sehen, wenn ich eine Terminvergabe und -pflege von mehreren Therapeuten gleichzeitig verwalten müsste.
Aber natürlich würde ich den Kalender selbst programmieren, bzw. etwas vorhandes entsprechend adaptieren. Da kann man bei der Anwenderfreundlichkeit viel mehr rausholen.

Eine Möglichkeit ist die oben erwähnte BillingInformation. Die gibt es glaube ich bei allen Item Objekten und vor allem muss man nicht in einer Schleife danach suchen. Es ist also eine schnelle Suche möglich.
LG Markus

 

\@ Markus: Prinzipiell eine gute Lösung, da wie du ja richtig festgestellt hast, ich in die Billinginformation die jeweilige Fall-ID eintrage. Nur:
1.) Leider ist dies nicht bei Serienterminen möglich
2.) Es reagiert sofort wenn ich eine Aufgabe in den Kalender ziehe. Hier ist jedoch noch nicht der Zeitrahmen des Termins definiert.
3.) ItemChange reagiert nicht auf Änderungen des Zeitrahmens.

@Andre: Wie kannst du wissen ob ein gewisser Termin möglich ist oder mit privaten oder anderen dienstlichen Terminen kollidiert, wenn du das von Access aus machst ? Hast du eine Kalenderfunktion integriert ?

Allgemein:
Vielleich meinen wir das selbe:

Ich erstelle auch die jeweilgen Termine von Access aus, sprich bevor Outlook gestartet wird, existieren alle Termine bereits in Access. => Dann erstelle ich diese als Aufgaben in Outlook mit einer jeweiligen Fall-ID in der Billing Information. Diese kann dann meine Frau in den Kalender ziehen und z.B. auch als Serientermin definieren. Über die Synchronisation werden dann nur Datum, Anfangszeit und Dauer in Access übertragen.

Ich habe noch eine Frage zu den Klassen. Ich benötige die Funktionalität von Oapp auch außerhalb der Klasse. Ich habe das nun so gelöst und es funktioniert, jedoch Ist das eine saubere Lösung, oder geht das besser ?

clsOutlook:

PHP:

         Option Explicit

Public WithEvents OApp As Outlook.Application
Public WithEvents OMapi As Outlook.NameSpace
Private WithEvents wKal As Items

Public Function DefO() As Outlook.Application
On Error Resume Next
If OApp = "Nothing" Then
Set OApp = GetObject(, "Outlook.Application")
If Err.Number = 429 Then
Set OApp = CreateObject("Outlook.Application")
End If
End If
Set DefO = OApp
End Function

Public Sub StartO()
DefO
If OApp.Explorers.Count = 0 Then
OApp.Session.GetDefaultFolder(olFolderCalendar).Display
OApp.ActiveExplorer.WindowState = olNormalWindow
OApp.ActiveExplorer.WindowState = olMaximized
OApp.ActiveExplorer.Display
Else
AppActivate OApp
End If
End Sub

Public Sub OApp_Quit()
Termine (1)
Set OApp = Nothing
End Sub


 

\@Shakes
Cool, dass du uns nun doch noch mit dem Konzept vertraut machst.
Das ändert natürlich alles.
-> zur Verwendung der Ereignissen, Auch wenn das trivial aussieht, ist dennoch ein gewisses Feingefühl erforderlich, damit das Ergebnis passt.

wenn Change nicht reagiert, dann war der Zeiger auf die Auflistung nicht gesetzt. Während der Entwicklung ist es leicht möglich, dass dieser Zeiger beim Testen zurückgesetzt wird. Wenn man dann nicht strukturiert sucht, glaubt man eben, dass es etwas nicht funktioniert.


LG Markus

 

Ich hab mit dem Outlook View Control den Outlook-Kalender "vor der Nase", wenn ich Termine in Access anlege, und vermeide Kollisionen ganz klassisch per "Hingucken". Das Aufsetzen entsprechender Prüfläufe in VBA war mir schlicht zu aufwendig ... *wink.gif*

Ich rede allerdings auch nur von meinem eigenen Kalender und meiner eigenen Terminplanung, da komme ich mit relativ einfachen Mitteln noch gut durch.