Procedure Request_Delete
| Call: | Send Request_Delete |
Request_Delete performs a delete operation by sending Request_Delete to the object's DataDictionary object (DDO) Server. If the DDO has no current record (nothing to delete), it just returns. An optional delete verification confirmation message may be presented. This message is only sent if the there is a current record and the data entry objects (DEO's) Verify_Delete_msg is set. This operation is performed using the RequestDeleteExec message as described below.
Note that this performs a DD Request_Delete operation. Deletes delete the record, deletes child records (if allowed) and updates parent records.
If the delete is successful, the part of the view involved in the delete will be cleared.
DEO objects may explicitly set their DDO server by placing a 'Set Server' line directly within the object. More often, DEO objects set their server implicitly by acquiring its server from an ancestor object via delegation. This way a group of DEOs can all share the same server. This is the recommended approach. When a server is not explicitly set, the Request_Delete message is delegated to the parent. This process is repeated until the DEO with the explicit server is found. Often this will be the view object itself. This means that all similar Request_Delete operations are handled by a single method in the view, making augmentation simpler.
When the browser client selects a save, delete, clear or clear-all, the message Request_Save, Request_Delete, Request_Clear or Request_Clear_All is sent to the server. These do a traditional DataFlex style request operation which is validation, verification and then the actual DD operation (Request_Save, Request_Delete, Clear, Clear_All). A verification is required based on the contents of Verify_Save_msg, Verify_Delete_msg and Verify_Data_Loss_msg. If a verification is required, the client needs to get involved to perform the user verification. This means that the operation requires an additional round trip. If the verification is accepted by the user, a message is sent to the server which handles part two of the request. Those part two messages are RequestSaveExec, RequestDeleteExec, RequestClearExec and RequestClearAllExec. These are the messages that attempt to actually perform the requested DD operation. You can think of these as "pre" and "post" messages.
If the verify messages are 0, which means that a user confirmation is not needed, the "pre" message (e.g. Request_Delete) will directly send the "post" message (e.g. RequestDeleteExec) without requiring an additional trip to the client.
Here is an rough outline of what happens with a Request_Delete (after the delegation to the DEO that sets the explicit server).
Request_Delete
If no current record return
If Verify_Delete_msg, tell client to present the verification and return *
Else Send RequestDeleteExec
RequestDeleteExec
Send Request_Delete to DDO
If no error
Clear the record and appropriate DEOs
* If the user confirms the operation, the client will make another server request which will indirectly send RequestDeleteExec
If you need to make a save, delete, clear, clear_all request manually (e.g., within a cWebButton) you should use Request_Save, Request_Delete, Request_Clear and Request_Clear_All and not these "exec" messages.
If you are augmenting these requests you need to be careful as they occur in two steps and it is possible that the second step (the exec) may not get called at all. Notice that the "pre" message (e.g., Request_Delete) may have actually performed the entire operation (if there is no verify message) or may have merely launched the operation which might be completed during the next server "post" request (e.g. RequestDeleteExec).