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

Searches

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

This is because when you use the following form of the search method, 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 the search method:
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, not in filterArgs, whose values are also treated as literals.

Why don't wildcards in search filters always work?

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

Why do I only get back 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