Freigeben über

Transaktionsverwaltung (Datenaustausch)

  • Artikel

Nach dem Einrichten einer Unterhaltung mit einem Server kann ein Client Transaktionen senden, um Daten und Dienste vom Server abzurufen.

In den folgenden Themen werden die Transaktionstypen beschrieben, die Clients für die Interaktion mit einem Server verwenden können.

Transaktion anfordern

Eine Clientanwendung kann die XTYP_REQUEST Transaktion verwenden, um ein Datenelement von einer Serveranwendung anzufordern. Der Client ruft die DdeClientTransaction-Funktion auf, gibt XTYP_REQUEST als Transaktionstyp an und gibt das datenelement an, das die Anwendung benötigt.

Die Dynamic Data Exchange Management Library (DDEML) übergibt die XTYP_REQUEST Transaktion an den Server und gibt den Themennamen, Elementnamen und das vom Client angeforderte Datenformat an. Wenn der Server das angeforderte Thema, element und format unterstützt, sollte der Server ein Datenhandle zurückgeben, das den aktuellen Wert des Elements identifiziert. Die DDEML übergibt dieses Handle an den Client als Rückgabewert von DdeClientTransaction. Der Server sollte NULL zurückgeben, wenn er das angeforderte Thema, Element oder Format nicht unterstützt.

DdeClientTransaction verwendet den lpdwResult-Parameter, um ein Transaktionsflag status an den Client zurückzugeben. Wenn der Server die XTYP_REQUEST Transaktion nicht verarbeitet, gibt DdeClientTransactionNULL zurück, und lpdwResult verweist auf das DDE_FNOTPROCESSED- oder DDE_FBUSY-Flag. Wenn das flag DDE_FNOTPROCESSED zurückgegeben wird, kann der Client nicht ermitteln, warum der Server die Transaktion nicht verarbeitet hat.

Wenn ein Server die XTYP_REQUEST Transaktion nicht unterstützt, sollte er das CBF_FAIL_REQUESTS Filterflag in der DdeInitialize-Funktion angeben. Dieses Flag verhindert, dass die DDEML die Transaktion an den Server sendet.

Poke-Transaktion

Ein Client kann nicht angeforderte Daten mit DdeClientTransaction an einen Server senden, um eine XTYP_POKE Transaktion an die Rückruffunktion eines Servers zu senden.

Die Clientanwendung erstellt zunächst einen Puffer, der die Daten enthält, die an den Server gesendet werden sollen, und übergibt dann einen Zeiger an den Puffer als Parameter an DdeClientTransaction. Alternativ kann der Client die DdeCreateDataHandle-Funktion verwenden, um ein Datenhandle abzurufen, das die Daten identifiziert, und das Handle dann an DdeClientTransaction übergeben. In beiden Fällen gibt der Client auch den Themennamen, Elementnamen und Datenformat an, wenn er DdeClientTransaction aufruft.

Die DDEML übergibt die XTYP_POKE Transaktion an den Server und gibt den Vom Client angeforderten Themennamen, Elementnamen und Datenformat an. Um das Datenelement und das Format zu akzeptieren, sollte der Server DDE_FACK zurückgeben. Um die Daten abzulehnen, sollte der Server DDE_FNOTPROCESSED zurückgeben. Wenn der Server zu ausgelastet ist, um die Daten zu akzeptieren, sollte der Server DDE_FBUSY zurückgeben.

Wenn DdeClientTransaction zurückgegeben wird, kann der Client den lpdwResult-Parameter verwenden, um auf das Flag "transaction-status" zuzugreifen. Wenn das Flag DDE_FBUSY ist, sollte der Client die Transaktion später erneut senden.

Wenn ein Server die XTYP_POKE Transaktion nicht unterstützt, sollte er das CBF_FAIL_POKES Filterflag in DdeInitialize angeben. Dieses Flag verhindert, dass die DDEML diese Transaktion an den Server sendet.

Transaktion beraten

Eine Clientanwendung kann die DDEML verwenden, um eine oder mehrere Links zu Elementen in einer Serveranwendung herzustellen. Wenn ein solcher Link eingerichtet wurde, sendet der Server regelmäßig Updates über das verknüpfte Element an den Client (in der Regel immer dann, wenn sich der Wert des Elements ändert, das der Serveranwendung zugeordnet ist). Durch die Verknüpfung wird eine Empfehlungsschleife zwischen den beiden Anwendungen eingerichtet, die an Ort und Stelle bleibt, bis der Client sie beendet.

Es gibt zwei Arten von Ratschlägeschleifen: "heiß" und "warm". In einer heißen Empfehlungsschleife sendet der Server sofort ein Datenhandle, das den geänderten Wert identifiziert. In einer warmen Empfehlungsschleife benachrichtigt der Server den Client, dass sich der Wert des Elements geändert hat, sendet jedoch das Datenhandle erst, wenn der Client es anfordert.

Ein Client kann eine hot advise-Schleife mit einem Server anfordern, indem er den XTYP_ADVSTART Transaktionstyp in einem Aufruf von DdeClientTransaction angibt. Um eine warme Beratungsschleife anzufordern, muss der Client das XTYPF_NODATA-Flag mit dem XTYP_ADVSTART Transaktionstyp kombinieren. In beiden Ereignissen übergibt die DDEML die XTYP_ADVSTART Transaktion an die DDE-Rückruffunktion (Dynamic Data Exchange) des Servers. Die DDE-Rückruffunktion des Servers sollte die Parameter untersuchen, die die XTYP_ADVSTART Transaktion begleiten (einschließlich des angeforderten Formats, des Themennamens und des Elementnamens) und dann TRUE zurückgeben, damit die Empfehlungsschleife oder FALSE die Transaktion verweigern kann.

Nachdem eine Empfehlungsschleife eingerichtet wurde, sollte die Serveranwendung die DdePostAdvise-Funktion aufrufen, wenn sich der Wert des Elements ändert, das dem angeforderten Elementnamen zugeordnet ist. Dieser Aufruf führt dazu, dass eine XTYP_ADVREQ Transaktion an die servereigene DDE-Rückruffunktion gesendet wird. Die DDE-Rückruffunktion des Servers sollte ein Datenhandle zurückgeben, das den neuen Wert des Datenelements identifiziert. Anschließend benachrichtigt die DDEML den Client, dass das angegebene Element geändert wurde, indem die XTYP_ADVDATA Transaktion an die DDE-Rückruffunktion des Clients gesendet wird.

Wenn der Client eine hot advise-Schleife angefordert hat, übergibt die DDEML das Datenhandle während der XTYP_ADVDATA Transaktion an das geänderte Element an den Client. Andernfalls kann der Client eine XTYP_REQUEST Transaktion senden, um das Datenhandle abzurufen.

Es ist möglich, dass ein Server Updates schneller sendet, als ein Client die neuen Daten verarbeiten kann. Die Geschwindigkeit von Updates kann ein Problem für einen Client sein, der langwierige Verarbeitungsvorgänge für die Daten ausführen muss. In diesem Fall sollte der Client das flag XTYPF_ACKREQ angeben, wenn er eine Empfehlungsschleife anfordert. Dieses Flag bewirkt, dass der Server wartet, bis der Client bestätigt, dass er ein Datenelement empfangen und verarbeitet hat, bevor der Server das nächste Datenelement sendet. Ratschlägeschleifen, die mit dem Flag XTYPF_ACKREQ eingerichtet sind, sind bei schnellen Servern robuster, können aber gelegentlich Updates verpassen. Ratschlägeschleifen, die ohne das flag XTYPF_ACKREQ eingerichtet wurden, verpassen garantiert keine Updates, solange der Client mit dem Server mithalten kann.

Ein Client kann eine Empfehlungsschleife beenden, indem er den XTYP_ADVSTOP Transaktionstyp in einem Aufruf von DdeClientTransaction angibt.

Wenn ein Server keine Empfehlungsschleifen unterstützt, sollte er das CBF_FAIL_ADVISES Filterflag in der DdeInitialize-Funktion angeben. Dieses Flag verhindert, dass die DDEML die XTYP_ADVSTART und XTYP_ADVSTOP Transaktionen an den Server sendet.

Transaktion ausführen

Ein Client kann die XTYP_EXECUTE Transaktion verwenden, um einen Server dazu zu veranlassen, einen Befehl oder eine Reihe von Befehlen auszuführen.

Um einen Serverbefehl auszuführen, erstellt der Client zuerst einen Puffer, der eine Befehlszeichenfolge für den Server für die Ausführung enthält, und übergibt dann entweder einen Zeiger auf den Puffer oder ein Datenhandle, das den Puffer identifiziert, wenn er DdeClientTransaction aufruft. Weitere erforderliche Parameter sind das Konversationshandle, das Elementnamenzeichenfolgenhandle, die Formatspezifikation und der XTYP_EXECUTE Transaktionstyps. Eine Anwendung, die ein Datenhandle zum Übergeben von Ausführungsdaten erstellt, muss NULL für den hszItem-Parameter der DdeCreateDataHandle-Funktion und null für den uFmt-Parameter angeben.

Die DDEML übergibt die XTYP_EXECUTE Transaktion an die DDE-Rückruffunktion des Servers und gibt den Formatnamen, das Konversationshandle, den Themennamen und das Datenhandle an, das die Befehlszeichenfolge identifiziert. Wenn der Server den Befehl unterstützt, sollte er die DdeAccessData-Funktion verwenden, um einen Zeiger auf die Befehlszeichenfolge abzurufen, den Befehl auszuführen und dann DDE_FACK zurückzugeben. Wenn der Server den Befehl nicht unterstützt oder die Transaktion nicht abschließen kann, sollte er DDE_FNOTPROCESSED zurückgeben. Der Server sollte DDE_FBUSY zurückgeben, wenn er zu ausgelastet ist, um die Transaktion abzuschließen.

Im Allgemeinen sollte die Rückruffunktion eines Servers die XTYP_EXECUTE Transaktion verarbeiten, bevor sie mit den folgenden Ausnahmen zurückgegeben wird:

  1. Wenn der Mit der XTYP_EXECUTE Transaktion übergebene Befehl den Server zum Beenden anfordert, sollte der Server erst beendet werden, wenn seine Rückruffunktion von der Verarbeitung XTYP_EXECUTE zurückgibt.
  2. Wenn der Server einen Vorgang ausführen muss, z. B. die Verarbeitung eines Dialogfelds oder einer DDE-Transaktion, die Probleme mit der DDEML-Rekursion verursachen kann, sollte der Server den CBR_BLOCK Rückgabecode zurückgeben, um die Ausführungstransaktion zu blockieren, den Vorgang auszuführen und dann die Verarbeitung der Ausführungstransaktion fortzusetzen.

Wenn DdeClientTransaction zurückgegeben wird, kann der Client den lpdwResult-Parameter verwenden, um auf die Transaktion status-Flag zuzugreifen. Wenn das Flag DDE_FBUSY ist, sollte der Client die Transaktion später erneut senden.

Wenn ein Server die XTYP_EXECUTE Transaktion nicht unterstützt, sollte er das CBF_FAIL_EXECUTES Filterflag in der DdeInitialize-Funktion angeben. Dadurch wird verhindert, dass die DDEML die Transaktion an den Server sendet.

Synchrone und asynchrone Transaktionen

Ein Client kann synchrone oder asynchrone Transaktionen senden. Bei einer synchronen Transaktion gibt der Client einen Timeoutwert an, der angibt, wie lange der Server maximal auf die Verarbeitung der Transaktion wartet. DdeClientTransaction wird erst zurückgegeben, wenn der Server die Transaktion verarbeitet, die Transaktion fehlschlägt oder der Timeoutwert abläuft. Der Client gibt den Timeoutwert an, wenn er DdeClientTransaction aufruft.

Während einer synchronen Transaktion tritt der Client in eine modale Schleife ein, während er auf die Verarbeitung der Transaktion wartet. Der Client kann weiterhin Benutzereingaben verarbeiten, aber keine weitere synchrone Transaktion senden, bis DdeClientTransaction zurückgibt.

Ein Client sendet eine asynchrone Transaktion, indem er das TIMEOUT_ASYNC-Flag in DdeClientTransaction angibt. Die Funktion gibt zurück, nachdem die Transaktion begonnen hat, und übergibt einen Transaktionsbezeichner an den Client. Wenn der Server die Verarbeitung der asynchronen Transaktion abgeschlossen hat, sendet die DDEML eine XTYP_XACT_COMPLETE Transaktion an den Client. Einer der Parameter, die die DDEML während der XTYP_XACT_COMPLETE Transaktion an den Client übergibt, ist der Transaktionsbezeichner. Durch den Vergleich dieses Transaktionsbezeichners mit dem von DdeClientTransaction zurückgegebenen Bezeichner identifiziert der Client, welche asynchrone Transaktion der Server die Verarbeitung abgeschlossen hat.

Ein Client kann die DdeSetUserHandle-Funktion als Hilfe bei der Verarbeitung einer asynchronen Transaktion verwenden. Diese Funktion ermöglicht es einem Client, einen anwendungsdefinierten Wert einem Konversationshandle und einem Transaktionsbezeichner zuzuordnen. Der Client kann die DdeQueryConvInfo-Funktion während der XTYP_XACT_COMPLETE Transaktion verwenden, um den von der Anwendung definierten Wert abzurufen. Aufgrund dieser Funktion muss eine Anwendung keine Liste mit aktiven Transaktionsbezeichnern verwalten.

Wenn ein Client eine Datenanforderung mithilfe einer synchronen Transaktion erfolgreich abschließt, kann die DDEML nicht sagen, wann der Client die empfangenen Daten verwendet hat. Die Clientanwendung muss das empfangene Datenhandle an die DdeFreeDataHandle-Funktion übergeben und die DDEML benachrichtigen, dass das Handle nicht mehr verwendet wird. Datenhandles, die von synchronen Transaktionen zurückgegeben werden, sind effektiv im Besitz des Clients.

Wenn ein Server eine asynchrone Transaktion nicht rechtzeitig verarbeitet, kann der Client die Transaktion beenden, indem er die DdeAbandonTransaction-Funktion aufruft. Die DDEML gibt alle Ressourcen frei, die der Transaktion zugeordnet sind, und verwirft die Ergebnisse der Transaktion, wenn der Server die Verarbeitung abgeschlossen hat. Ein Timeout während einer synchronen Transaktion bricht die Transaktion effektiv ab.

Die asynchrone Transaktionsmethode wird für Anwendungen bereitgestellt, die eine große Menge von DDE-Transaktionen senden müssen, während gleichzeitig ein beträchtlicher Verarbeitungsaufwand ausgeführt werden muss, z. B. die Durchführung von Berechnungen. Die asynchrone Methode ist auch in Anwendungen nützlich, die die Verarbeitung von DDE-Transaktionen vorübergehend beenden müssen, damit sie andere Aufgaben ohne Unterbrechung ausführen können. In den meisten anderen Situationen sollte eine Anwendung die synchrone Methode verwenden.

Synchrone Transaktionen sind einfacher zu verwalten und schneller als asynchrone Transaktionen. Es kann jedoch nur eine synchrone Transaktion gleichzeitig ausgeführt werden, während viele asynchrone Transaktionen gleichzeitig ausgeführt werden können. Bei synchronen Transaktionen kann ein langsamer Server dazu führen, dass ein Client im Leerlauf bleibt, während er auf eine Antwort wartet. Außerdem führen synchrone Transaktionen dazu, dass der Client in eine modale Schleife wechselt, die die Nachrichtenfilterung in der eigenen Nachrichtenschleife der Anwendung umgehen könnte.

Wenn der Client eine Hookprozedur zum Filtern von Nachrichten installiert hat (d. h. den WH_MSGFILTER Hooktyp in einem Aufruf der SetWindowsHookEx-Funktion angegeben hat), führt eine synchrone Transaktion nicht dazu, dass das System die Hookprozedur umgehen kann. Wenn ein Eingabeereignis auftritt, während der Client auf das Beenden einer synchronen Transaktion wartet, empfängt die Hookprozedur einen MSGF_DDEMGR Hookcode. Die Standard Gefahr, eine synchrone Transaktions-Modalschleife zu verwenden, besteht darin, dass eine modale Schleife, die von einem Dialogfeld erstellt wird, den Betrieb beeinträchtigen kann. Asynchrone Transaktionen sollten immer verwendet werden, wenn die DDEML von einer DLL verwendet wird.

Transaktionssteuerung

Eine Anwendung kann Transaktionen mit ihrer DDE-Rückruffunktion entweder die Transaktionen, die einem bestimmten Konversationshandle zugeordnet sind, oder alle Transaktionen unabhängig vom Konversationshandle anhalten. Diese Funktion ist nützlich, wenn eine Anwendung eine Transaktion empfängt, die eine langwierige Verarbeitung erfordert. In einem solchen Fall kann die Anwendung den CBR_BLOCK Rückgabecode zurückgeben, um zukünftige Transaktionen auszusetzen, die dem Konversationshandle der Transaktion zugeordnet sind, sodass die Anwendung andere Unterhaltungen verarbeiten kann.

Nach Abschluss der Verarbeitung ruft die Anwendung die DdeEnableCallback-Funktion auf, um Transaktionen fortzusetzen, die der angehaltenen Unterhaltung zugeordnet sind. Das Aufrufen von DdeEnableCallback bewirkt, dass die DDEML die Transaktion erneut angibt, was dazu führte, dass die Anwendung die Unterhaltung ansetzte. Daher sollte die Anwendung das Ergebnis der Transaktion so speichern, dass sie das Ergebnis abrufen und zurückgeben kann, ohne die Transaktion erneut zu verarbeiten.

Eine Anwendung kann alle Transaktionen anhalten, die einem bestimmten Konversationshandle zugeordnet sind, indem sie das Handle und das EC_DISABLE-Flag in einem Aufruf von DdeEnableCallback angibt. Durch Angabe eines NULL-Handles kann eine Anwendung alle Transaktionen für alle Unterhaltungen anhalten.

Wenn eine Unterhaltung angehalten wurde, speichert die DDEML Transaktionen für die Unterhaltung in einer Transaktionswarteschlange. Wenn die Anwendung die Konversation erneut aufruft, entfernt die DDEML die gespeicherten Transaktionen aus der Warteschlange und übergibt jede Transaktion an die entsprechende Rückruffunktion. Die Kapazität der Transaktionswarteschlange ist groß, aber eine Anwendung sollte eine angehaltene Unterhaltung so schnell wie möglich wieder herstellen, um den Verlust von Transaktionen zu vermeiden.

Eine Anwendung kann die übliche Transaktionsverarbeitung fortsetzen, indem sie das EC_ENABLEALL-Flag in DdeEnableCallback angibt. Für eine kontrolliertere Wiederaufnahme der Transaktionsverarbeitung kann die Anwendung das flag EC_ENABLEONE angeben. Dieses Flag entfernt eine Transaktion aus der Transaktionswarteschlange und übergibt sie an die entsprechende Rückruffunktion. nachdem diese Transaktion verarbeitet wurde, werden alle Unterhaltungen wieder deaktiviert.

Wenn das EC_ENABLEONE-Flag und ein Konversationshandle im Aufruf von DdeEnableCallback angegeben sind, wird nur diese Unterhaltung blockiert, nachdem die Transaktion verarbeitet wurde. Wenn ein NULL-Konversationshandle angegeben wird, werden alle Unterhaltungen blockiert, nachdem eine Transaktion in einer Unterhaltung verarbeitet wurde.

Transaktionsklassen

Die DDEML verfügt über vier Transaktionsklassen. Jede Klasse wird durch eine Konstante identifiziert, die mit dem präfix XCLASS_ beginnt. Die Klassen werden in der DDEML-Headerdatei definiert. Der Klassenwert wird mit dem Transaktionstypwert kombiniert und an die DDE-Rückruffunktion der empfangenden Anwendung übergeben.

Die Klasse einer Transaktion bestimmt den Rückgabewert, den eine Rückruffunktion zurückgeben soll, wenn sie die Transaktion verarbeitet. Die folgenden Rückgabewerte und Transaktionstypen sind jeder der vier Transaktionsklassen zugeordnet.

Klasse Rückgabewert Transaktion
XCLASS_BOOL TRUE oder FALSE XTYP_ADVSTART
XTYP_CONNECT
XCLASS_DATA Ein Datenhandle, das CBR_BLOCK Rückgabecode oder NULL XTYP_ADVREQ
XTYP_REQUEST
XTYP_WILDCONNECT
XCLASS_FLAGS Ein Transaktionsflag: DDE_FACK, DDE_FBUSY oder DDE_FNOTPROCESSED XTYP_ADVDATA
XTYP_EXECUTE
XTYP_POKE
XCLASS_NOTIFICATION Keine XTYP_ADVSTOP
XTYP_CONNECT_CONFIRM
XTYP_DISCONNECT
XTYP_ERROR
XTYP_REGISTER
XTYP_UNREGISTER
XTYP_XACT_COMPLETE

Transaktionstypen

Jeder DDE-Transaktionstyp verfügt über einen Empfänger und eine zugeordnete Aktivität, die dazu führt, dass die DDEML jeden Typ generiert.

Transaktionstyp Receiver Ursache
XTYP_ADVDATA Client Ein Server hat auf eine XTYP_ADVREQ Transaktion geantwortet , indem er ein Datenhandle zurückgibt.
XTYP_ADVREQ Server Ein Server namens DdePostAdvise , der angibt, dass sich der Wert eines Datenelements in einer Empfehlungsschleife geändert hat.
XTYP_ADVSTART Server Ein Client hat den XTYP_ADVSTART Transaktionstyp in einem Aufruf der DdeClientTransaction-Funktion angegeben.
XTYP_ADVSTOP Server Ein Client hat den XTYP_ADVSTOP Transaktionstyp in einem Aufruf von DdeClientTransaction angegeben.
XTYP_CONNECT Server Ein Client hat die DdeConnect-Funktion aufgerufen und einen Dienst- und Themennamen angegeben, der vom Server unterstützt wird.
XTYP_CONNECT_CONFIRM Server Der Server hat als Reaktion auf eine XTYP_CONNECT oder XTYP_WILDCONNECT Transaktion TRUE zurückgegeben.
XTYP_DISCONNECT Client/Server Ein Partner in einer Unterhaltung mit dem Namen DdeDisconnect-Funktion , wodurch beide Partner diese Transaktion empfangen.
XTYP_ERROR Client/Server Ein kritischer Fehler ist aufgetreten. Die DDEML verfügt möglicherweise nicht über ausreichende Ressourcen, um fortzufahren.
XTYP_EXECUTE Server Ein Client hat den XTYP_EXECUTE Transaktionstyp in einem Aufruf von DdeClientTransaction angegeben.
XTYP_MONITOR DDE-Überwachungsanwendung Im System ist ein DDE-Ereignis aufgetreten. Weitere Informationen zu DDE-Überwachungsanwendungen finden Sie unter Überwachen von Anwendungen.
XTYP_POKE Server Ein Client hat den XTYP_POKE Transaktionstyp in einem Aufruf von DdeClientTransaction angegeben.
XTYP_REGISTER Client/Server Eine Serveranwendung hat die DdeNameService-Funktion verwendet, um einen Dienstnamen zu registrieren.
XTYP_REQUEST Server Ein Client hat den XTYP_REQUEST Transaktionstyp in einem Aufruf von DdeClientTransaction angegeben.
XTYP_UNREGISTER Client/Server Eine Serveranwendung hat DdeNameService verwendet, um die Registrierung eines Dienstnamens aufzuheben.
XTYP_WILDCONNECT Server Ein Client namens DdeConnect oder DdeConnectList , der NULL für den Dienstnamen, den Themennamen oder beides angibt.
XTYP_XACT_COMPLETE Client Eine asynchrone Transaktion, die gesendet wurde, wenn der Client das flag TIMEOUT_ASYNC in einem Aufruf von DdeClientTransaction angegeben hat, wurde abgeschlossen.