Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für: Outlook 2013 | Outlook 2016
Ein Nachrichtenspeicher schreibgeschützt ist eine in die weder der MAPI-Client noch die MAPI-Warteschlange kann erstellen, ändern oder löschen Sie die Objekte im Nachrichtenspeicher. Es gibt viele Gründe, warum Sie möglicherweise einen schreibgeschützten Nachrichtenspeicher implementieren möchten. Beispielsweise konnte Credit reporting Firma einen nur-Lese-Speicher verwenden, um die Kunden oder Mitarbeiter finden Sie unter aber nicht ändern einzelne Credit Berichte zu ermöglichen. Stellen Sie einen schreibgeschützten Nachrichtenspeicher Auswahl hat Auswirkungen auf für die Struktur des Anbieters und der Store selbst abzurufen. Beispielsweise ein Nachrichtenspeicher schreibgeschützt sind keinen Ordner Postausgang, da dann MAPI-Clients würde anfordern, dass neue ausgehende Nachrichten in diesem Ordner erstellt werden. In ähnlicher Weise ist es vom Informationsdienst dafür verantwortlich, die Integrität der zugrunde liegende Speichermechanismus sicherzustellen.
In der Eigenschaft PR_STORE_SUPPORT_MASK (PidTagStoreSupportMask) des Nachrichtenspeichers können drei Flags festgelegt werden, die unterschiedliche Ebenen des schreibgeschützten Zugriffs unterstützen. The STORE_READONLY flag indicates that all IMAPIProp: IUnknown interfaces on objects in the message store are read-only. The STORE_MODIFY_OK flag indicates that existing messages in the message store may be modified, but new folders and messages may not be created. The STORE_CREATE_OK flag indicates that new messages and folders may be created, but indicates nothing about whether existing objects may be modified.
Die Tatsache, dass MAPI-Clients und die MAPI-Warteschlange nicht möglich ist, erstellen, ändern oder Löschen von Objekten im Nachrichtenspeicher bedeutet nicht, dass den Inhalt der zugrunde liegende Speichermechanismus niemals ändern. Noch bedeutet dies, dass Ihre Speicheranbieter nie Berechtigung in der zugrunde liegende Speichermechanismus zu schreiben muss. In einigen Fällen können diese beiden Bedingungen anwenden, jedoch nicht im Allgemeinen einer nur-Lese-Nachricht speichern. Die Zugriffsebene, dass ein Speicheranbieter erfordert und ob ein Speicheranbieter jemals Daten in der zugrunde liegende Speichermechanismus ändert hängt im Wesentlichen die Art der einen Speicheranbieter.
Beispielsweise wenn Sie einen Anbieter anmelden, um MAPI-Clients Zugriff auf eine Datenbank auf einem CD-ROM-Gerät gewähren schreiben, der zugrunde liegende Speichermechanismus kann nicht geändert werden und ein Speicheranbieter Leseberechtigung dafür haben kann. Wenn jedoch Sie einen Anbieter anmelden schreiben, um MAPI-Clients schreibgeschützten Zugriff auf öffentliche Ordner-Datenbank zu ermöglichen, Speicheranbieter muss jedoch zum Nachverfolgen von Nachrichten für jeden Benutzer, den gelesen/ungelesen Status müssen vom Informationsdienst neue Daten in der zugrunde liegende Speichermechanismus zu schreiben. Jedoch ist weder Beispiel Speicheranbieter jemals erforderlich, erstellen, Ändern oder Löschen von Ordnern und Nachrichten an die Anforderung des MAPI-Clients oder die MAPI-Warteschlange.
Die kleine Gruppe von Gründe, die ein Anbieter anmelden muss Daten in eine zugrunde liegende Speichermechanismus zu schreiben, die andernfalls schreibgeschützt ist, lautet wie folgt:
Gelesen/ungelesen Status von Nachrichten gespeichert.
Lese-/Nonread Benachrichtigungen zu implementieren.
Zum Speichern von Ansichten.
Beständige Indizes für benutzerdefinierte Ordner Sortierreihenfolgen zwischengespeichert.
To store the sort order of a folder's contents (supporting IMAPIFolder::SaveContentsSort).
To store search criteria, search state, and results, if the message store provider supports searches (supporting IMAPIContainer::SetSearchCriteria).
Wenn Ihre Nachricht Speicheranbieter nie Daten in der zugrunde liegende Speichermechanismus schreiben kann, müssen sie diese Features mithilfe eines separaten Speichermechanismus außerhalb der zugrunde liegende Speichermechanismus implementieren. Beispielsweise könnte ein Anbieter für schreibgeschützte Nachricht anmelden gelesen/ungelesen Status von Nachrichten in den Speicher in einer Datei auf dem Computer des Benutzers speichern. Diese Strategie stellt zusätzliche Schwierigkeiten aber möglicherweise nur anteilmäßige wie für schreibgeschützte Nachricht Anbieter einige Funktionen zu implementieren. Halten den Inhalt des separater Speichervolumes Mechanismus mit den Objekten im Nachrichtenspeicher synchronisiert ist beispielsweise schwieriger als das Speichern des gelesen/ungelesen Status direkt in der Nachricht-Store selbst abzurufen.
Suche bietet eine zusätzliche Schwierigkeit für schreibgeschützte Nachricht-Anbieter. Clients verwenden den Ordner, der in der Eigenschaft PR_FINDER_ENTRYID (PidTagFinderEntryId) des Nachrichtenspeicherobjekts angegeben ist, um den Ordner zu suchen, der für Suchergebnisse verwendet wird. Schreibgeschützte Nachricht Anbieter installieren nicht häufig einen Ordner permanent Suchergebnisse in die Nachrichtenspeicher. In diesem Fall sollte der Nachricht Informationsdienst einen Eintrag Bezeichner in der PR_FINDER_ENTRYID -Eigenschaft speichern, die es erkennen kann, wenn Clients Ordner öffnen, sodass es einen Suchergebnisse Ordner anstelle von Lesen aus der zugrunde liegende Speichermechanismus dynamisch erstellen kann. Da viele schreibgeschützte Nachricht Anbieter dynamisch allen Ordnern zu erstellen, ist dies jedoch in der Regel nicht zu viel in der Regel.
In das Store-Anbieter-Objekt PR_STORE_SUPPORT_MASK -Eigenschaft ist die Tatsache, dass Ihre Nachricht Speicheranbieter schreibgeschützt ist angekündigt. Zählen Sie jedoch nicht auf Clients berücksichtigen diese Eigenschaft; einen Speicheranbieter Code sollte den schreibgeschützten Status der zugrunde liegende Speichermechanismus erzwingen.