Zusammenarbeit von Ereignishandlern

Sofern Sie nicht in Visual Basic programmieren, müssen alle Ereignishandler für Connection und Recordset--Ereignisse implementiert werden, unabhängig davon, ob Sie tatsächlich alle Ereignisse verarbeiten. Die Menge der Implementierungsaufgaben, die Sie ausführen müssen, hängt von Ihrer Programmiersprache ab. Weitere Informationen finden Sie unter ADO-Ereigniserzeugung nach Sprache.

Gekoppelte Ereignishandler

Jeder Will-Ereignishandler verfügt über einen zugeordneten Complete Ereignishandler. Wenn ihre Anwendung beispielsweise den Wert eines Felds ändert, wird der WillChangeField Ereignishandler aufgerufen. Wenn die Änderung akzeptabel ist, lässt Ihre Anwendung den adStatus Parameter unverändert, und der Vorgang wird ausgeführt. Wenn der Vorgang abgeschlossen ist, benachrichtigt ein FieldChangeComplete--Ereignis die Anwendung, dass der Vorgang abgeschlossen ist. Wenn sie erfolgreich abgeschlossen wurde, enthält adStatus-adStatusOK-; andernfalls enthält adStatus-adStatusErrorsOccurred, und Sie müssen das Error-Objekt überprüfen, um die Ursache des Fehlers zu ermitteln.

Wenn WillChangeField aufgerufen wird, können Sie feststellen, dass die Änderung möglicherweise nicht vorgenommen werden soll. Legen Sie in diesem Fall adStatus- auf adStatusCancel fest. Der Vorgang wird abgebrochen, und das FieldChangeComplete--Ereignis empfängt einen adStatus- Wert von adStatusErrorsOccurred. Das Error-Objekt enthält adErrOperationCancelled, sodass ihr FieldChangeComplete--Handler weiß, dass der Vorgang abgebrochen wurde. Sie müssen jedoch den Wert des adStatus- Parameters überprüfen, bevor Sie ihn ändern, da das Festlegen adStatus- auf adStatusCancel keine Auswirkung hat, wenn der Parameter auf adStatusCantDeny für den Eintrag in die Prozedur festgelegt wurde.

Manchmal kann ein Vorgang mehrere Ereignisse auslösen. Das Recordset-objekt-Objekt verfügt beispielsweise über gekoppelte Ereignisse für Field Änderungen und Datensatzänderungen. Wenn die Anwendung den Wert eines Fieldändert, wird der WillChangeField- Ereignishandler aufgerufen. Wenn festgestellt wird, dass der Vorgang fortgesetzt werden kann, wird auch der WillChangeRecord Ereignishandler ausgelöst. Wenn dieser Handler auch das Fortsetzen des Ereignisses zulässt, wird die Änderung vorgenommen, und die FieldChangeComplete und RecordChangeComplete Ereignishandler werden aufgerufen. Die Reihenfolge, in der die Will-Ereignishandler für einen bestimmten Vorgang aufgerufen werden, ist nicht definiert. Daher sollten Sie das Schreiben von Code vermeiden, der von aufrufenden Handlern in einer bestimmten Sequenz abhängt.

In Fällen, in denen mehrere Will-Ereignisse ausgelöst werden, kann eines der Ereignisse den ausstehenden Vorgang abbrechen. Wenn Ihre Anwendung beispielsweise den Wert eines Fieldändert, werden normalerweise die Ereignishandler -WillChangeField- und -WillChangeRecord- aufgerufen. Wenn der Vorgang jedoch im ersten Ereignishandler abgebrochen wird, wird der zugeordnete Complete-Handler sofort mit adStatusOperationCancelledaufgerufen. Der zweite Handler wird nie aufgerufen. Wenn jedoch der erste Ereignishandler das Fortsetzen des Ereignisses zulässt, wird der andere Ereignishandler aufgerufen. Wenn es dann den Vorgang abbricht, werden beide Complete-Ereignisse wie in den vorherigen Beispielen aufgerufen.

Nicht gekoppelte Ereignishandler

Solange der an das Ereignis übergebene Status nicht adStatusCantDenyist, können Sie Ereignisbenachrichtigungen für jedes Ereignis deaktivieren, indem Sie adStatusUnwantedEvent- im parameter Status zurückgeben. Wenn Ihr Complete-Ereignishandler das erste Mal aufgerufen wird, können Sie adStatusUnwantedEventzurückgeben. Anschließend erhalten Sie nur Will-Ereignisse. Einige Ereignisse können jedoch aus mehr als einem Grund ausgelöst werden. In diesem Fall verfügt das Ereignis über einen Reason-Parameter. Wenn Sie adStatusUnwantedEventzurückgeben, erhalten Sie nur dann keine Benachrichtigungen mehr für dieses Ereignis, wenn sie aus diesem bestimmten Grund auftreten. Mit anderen Worten, Sie erhalten möglicherweise Benachrichtigungen aus jedem möglichen Grund, dass das Ereignis ausgelöst werden kann.

Einzelne Wird Ereignishandler können nützlich sein, wenn Sie die Parameter untersuchen möchten, die in einem Vorgang verwendet werden. Sie können diese Vorgangsparameter ändern oder den Vorgang abbrechen.

Lassen Sie alternativ " Ereignisbenachrichtigung abgeschlossen" aktiviert. Wenn der erste Will-Ereignishandler aufgerufen wird, geben Sie adStatusUnwantedEventzurück. Anschließend erhalten Sie nur Complete-Ereignisse.

Einzelne -Complete--Ereignishandler können für die Verwaltung asynchroner Vorgänge nützlich sein. Jeder asynchrone Vorgang verfügt über ein entsprechendes Complete-Ereignis.

Es kann z. B. lange dauern, bis ein großes Recordset-Objekt aufgefüllt wird. Wenn Ihre Anwendung entsprechend geschrieben wurde, können Sie einen Recordset.Open(...,adAsyncExecute) Vorgang starten und mit der anderen Verarbeitung fortfahren. Sie werden schließlich benachrichtigt, wenn das Recordset- durch ein ExecuteComplete--Ereignis aufgefüllt wird.

Einzelne Ereignishandler und mehrere Objekte

Die Flexibilität einer Programmiersprache wie Visual C++ ermöglicht es Ihnen, dass ein Ereignishandler Ereignisse von mehreren Objekten verarbeitet. Sie könnten beispielsweise einen Disconnect Ereignishandler haben, der Ereignisse aus mehreren Connection-Objekten verarbeitet. Wenn eine der Verbindungen beendet wurde, wird der Disconnect-Ereignishandler aufgerufen. Sie könnten feststellen, welche Verbindung das Ereignis verursacht hat, da der Ereignishandlerobjektparameter auf das entsprechende Connection-Objekt festgelegt wurde.

Anmerkung

Diese Technik kann in Visual Basic nicht verwendet werden, da diese Sprache nur ein Objekt mit einem Ereignishandler korrelieren kann.

Siehe auch

ADO-Ereignishandler-Zusammenfassung
ADO-Ereignisinstanziierung nach Sprache
Ereignisparameter
Ereignistypen