Previous | Next | Trail Map | Tips for LDAP Users | Frequently Asked Questions

Searches

Why does putting an "*" as an attribute value not work as expected in my search?

When you use the following form of search(), the attribute values are treated as literals; that is, the attribute in the directory entry is expected to contain exactly that value:
search(Name name, Attributes matchingAttrs)(in the API reference documentation)
To use wildcards, you should use the string filter forms of search(), as follows.
search(Name name, String filter, SearchControls ctls)(in the API reference documentation)
search(Name name, String filterExpr, Object[]filterArgs, SearchControls ctls)(in the API reference documentation)
For the last form, the wildcard characters must appear in the filterExpr argument, and not in filterArgs. The values in filterArgs are also treated as literals.

Why don't wildcards in search filters always work?

A wildcard that appears before or after the attribute value (such as in "attr=*I*") indicates that the server is to search for matching attribute values by using the attribute's substring matching rule. If the attribute's definition does not have a substring matching rule, then the server cannot find the attribute. You'll have to search by using an equality or "present" filter instead.

Why do I get back only n number of entries when I know there are more in the directory?

Some servers are configured to limit the number of entries that can be returned. Others also limit the number of entries that can be examined during a search. Check your server configuration.

How do I pass controls with my search?

See the Controls and Extensions (in the Tips for LDAP Users trail) lesson for details.

How do I find out how many search results I got back?

You must keep count as you enumerate through the results. The LDAP does not provide this information.


Previous | Next | Trail Map | Tips for LDAP Users | Frequently Asked Questions