Filtering is the way the request XML packet indicates the object to which the operation will be applied. The request XML filters data using a special <filter> section. A single filter can specify multiple database users, all specified either by ID or by database ID. It also can match multiple databases, specified either by ID, subscription ID, or subscription name.

Parameters, nested in the filter node are called filtering rule. A filter contains as many different filtering rule types as the number of different parameters nested in the XML presentation of the filter node. A single operation can use only parameters of the same type in the filtering rule.


The filter node is of data type DatabaseFilterType (database_input.xsd) which has the following graphical presentation:

image 66325

  • The id node is optional. It specifies the ID of a database. Data type: integer.
  • The webspace-id node is optional. It specifies the ID of the subscription on which a database is added. Data type: integer.
  • The webspace-name node is optional. It specifies the name of the subscription on which a database is added. Data type: string (Unicode).

A packet that retrieves information about databases on subscription can look as follows:

<packet version="">

image 75351

If an operation uses filters in a request packet (del-db-user, get-db, get-db-users, get-default-user, del-db, assign-to-subscription), the filter-id node is nested in a response packet. It returns the filtering rule parameter. If one of the following values was set as a filter rule parameter, it is returned in the filter-id node of the response packet:

  • database ID
  • subscription name
  • subscription ID
  • database user ID

It is done so to trace the request parameters in case of an error. Data type: anySimple.

If the filter node is left blank (<filter/>), the filter-id parameter will hold the ID of the object. The blank filter means that all objects (like databases or database users) are matched by this rule.