HP OpenVMS Systems Documentation |
OpenVMS Utility Routines Manual
13.14 Deleting an EntryThe following functions are used to delete a leaf entry from the LDAP directory. There are four variations.
Parameters are as follows:
Note that the entry to delete must be a leaf entry (that is, it must have no children). Deletion of entire subtrees in a single operation is not supported by LDAP. The ldap_delete_ext() function initiates an asynchronous delete operation and returns either the constant LDAP_SUCCESS if the request was successfully sent or another LDAP error code if not. See Section 13.18 for more information about possible errors and how to interpret them. If successful, ldap_delete_ext() places the message id of the request in *msgidp. A subsequent call to ldap_result() can be used to obtain the result of the delete. Similar to ldap_delete_ext() , the ldap_delete() function initiates an asynchronous delete operation and returns the message id of the operation initiated. As for ldap_delete_ext() , a subsequent call to ldap_result() can be used to obtain the result of the delete. In case of error, ldap_delete() will return -1, setting the session error parameters in the LDAP structure appropriately. The synchronous ldap_delete_ext_s() and ldap_delete_s() functions both return the result of the operation, either the constant LDAP_SUCCESS if the operation was successful or another LDAP error code if it was not. See Section 13.18 for more information about possible errors and how to interpret them.
The
ldap_delete_ext()
and
ldap_delete_ext_s()
functions support LDAPv3 server controls and client controls.
The ldap_extended_operation() and ldap_extended_operation_s() functions allow extended LDAP operations to be passed to the server, providing a general protocol extensibility mechanism.
Parameters are as follows:
The ldap_extended_operation() function initiates an asynchronous extended operation and returns either the constant LDAP_SUCCESS if the request was successfully sent or another LDAP error code if not. See Section 13.18 for more information about possible errors and how to interpret them. If successful, ldap_extended_operation() places the message id of the request in *msgidp. A subsequent call to ldap_result() can be used to obtain the result of the extended operation which can be passed to ldap_parse_extended_result() to obtain the OID and data contained in the response. The synchronous ldap_extended_operation_s() function returns the result of the operation, either the constant LDAP_SUCCESS if the operation was successful or another LDAP error code if it was not. See Section 13.18 for more information about possible errors and how to interpret them. The retoid and retdata parameters are filled in with the OID and data from the response. If no OID or data was returned, these parameters are set to NULL.
The
ldap_extended_operation()
and
ldap_extended_operation_s()
functions both support LDAPv3 server controls and client controls.
The following calls are used to abandon an operation in progress:
Parameters are as follows:
The ldap_abandon_ext() function abandons the operation with message id msgid and returns either the constant LDAP_SUCCESS if the abandon was successful or another LDAP error code if not. See Section 13.18 for more information about possible errors and how to interpret them. The ldap_abandon() function is identical to ldap_abandon_ext() except that it does not accept client or server controls and it returns zero if the abandon was successful, -1 otherwise and does not support LDAPv3 server controls or client controls.
After a successful call to
ldap_abandon()
or
ldap_abandon_ext()
, results with the given message id are never returned from a
subsequent call to
ldap_result()
. There is no server response to LDAP abandon operations.
The ldap_result() function is used to obtain the result of a previous asynchronously initiated operation. Note that depending on how it is called, ldap_result() may actually return a list or "chain" of result messages. Once a chain of messages has been returned to the caller, it is no longer tied in any caller-visible way to the LDAP request that produced it. Therefore, a chain of messages returned by calling ldap_result() or by calling a synchronous search function will never be affected by subsequent LDAP API calls (except for ldap_msgfree() , which is used to dispose of a chain of messages). The ldap_msgfree() function frees the result messages (possibly an entire chain of messages) obtained from a previous call to ldap_result() or from a call to a synchronous search function. The ldap_msgtype() function returns the type of an LDAP message. The ldap_msgid() function returns the message ID of an LDAP message.
Parameters are as follows:
Upon successful completion, ldap_result() returns the type of the first result returned in the res parameter. This will be one of the following constants.
The ldap_result() function returns 0 if the timeout expired and -1 if an error occurs, in which case the error parameters of the LDAP session handle will be set accordingly. The ldap_msgfree() function frees the result structure pointed to by res and returns the type of the message it freed. The ldap_msgtype() function returns the type of the LDAP message it is passed as a parameter. The type will be one of the types listed above, or -1 on error.
The
ldap_msgid()
function returns the message ID associated with the LDAP message passed
as a parameter.
The following calls are used to extract information from results and handle errors returned by other LDAP API functions. Note that ldap_parse_sasl_bind_result() and ldap_parse_extended_result() must typically be used in addition to ldap_parse_result() to retrieve all the result information from SASL bind and extended operations, respectively.
The use of the following functions is deprecated.
Parameters are as follows:
Additional parameters for the deprecated functions are not described. See RFC 1823 for more information. All three of the ldap_parse_*_result() functions skip over messages of type LDAP_RES_SEARCH_ENTRY and LDAP_RES_SEARCH_REFERENCE when looking for a result message to parse. They return either the constant LDAP_SUCCESS if the result was successfully parsed or another LDAP error code if not. Note that the LDAP error code that indicates the outcome of the operation performed by the server is placed in the errcodep ldap_parse_result() parameter. If a chain of messages that contains more than one result message is passed to these functions, they always operate on the first result in the chain.
The
ldap_err2string()
function is used to convert a numeric LDAP error code, as returned by
either one of the three
ldap_parse_*_result()
functions or one of the synchronous API operation calls, into an
informative zero-terminated character string message describing the
error. It returns a pointer to static data.
The ldap_first_message() and ldap_next_message() functions are used to step through the list of messages in a result chain returned by ldap_result() . For search operations, the result chain may actually include referral messages, entry messages, and result messages. The ldap_count_messages() function is used to count the number of messages returned. The ldap_msgtype() function can be used to distinguish between the different message types.
Parameters are as follows:
The ldap_first_message() and ldap_next_message() functions will return NULL when no more messages exist in the result set to be returned. NULL is also returned if an error occurs while stepping through the entries, in which case the error parameters in the session handle ld will be set to indicate the error. The ldap_count_messages() function returns the number of messages contained in a chain of results. It can also be used to count the number of messages that remain in a chain if called with a message, entry, or reference returned by ldap_first_message() , ldap_next_message() , ldap_first_entry() , ldap_next_entry() , ldap_first_reference() , ldap_next_reference() .
|