From: Olaf.Schneider@Materna.DE Hello Leif! Using the object-orientated Ldap Interface i've had the following problem: If the result of a search operation is greater then the LDAP_SIZELIMIT or LDAP_ADMINLIMIT the search Method drops the result and delivers the perl script an empty result. I have fixed this bug temporary with the following change (line 19-23 and 31-36 and in the function search URL). Maybe we should set a variable in the conn object so that the programmer can determine that the limit was exceeded. 00 ############################################################################# 01 # Normal LDAP search. Note that this will actually perform LDAP URL searches 02 # if the filter string looks like a proper URL. 03 # 04 sub search 05 { 06 my ($self, $basedn, $scope, $filter, $attrsonly, @attrs) = @_; 07 my ($resv, $entry); 08 my $res = \$resv; 09 10 $scope = Mozilla::LDAP::Utils::str2Scope($scope); 11 $filter = "(objectclass=*)" if ($filter =~ /^ALL$/i); 12 13 if (defined($self->{"ldres"})) 14 { 15 ldap_msgfree($self->{"ldres"}); 16 undef $self->{"ldres"}; 17 } 18 if (ldap_is_ldap_url($filter)) 19 { my $rc; 20 $rc=ldap_url_search_s($self->{"ld"}, $filter, $attrsonly, $res); 21 22 if (rc==LDAP_SUCCESS || rc==LDAP_TIMELIMIT_EXCEEDED || 23 rc==LDAP_SIZELIMIT_EXCEEDED ||rc==LDAP_ADMINLIMIT_EXCEEDED) 24 { 25 $self->{"ldres"} = $res; 26 $self->{"ldfe"} = 1; 27 $entry = $self->nextEntry(); 28 } 29 } 30 else 31 { my $rc; 32 $rc = ldap_search_s($self->{"ld"}, $basedn, $scope, $filter, \@attrs, 33 $attrsonly, $res); 34 if (rc==LDAP_SUCCESS || rc==LDAP_TIMELIMIT_EXCEEDED || 35 rc==LDAP_SIZELIMIT_EXCEEDED ||rc==LDAP_ADMINLIMIT_EXCEEDED) 36 { 37 $self->{"ldres"} = $res; 38 $self->{"ldfe"} = 1; 39 $entry = $self->nextEntry(); 40 } 41 } 42 43 return $entry; 44 } bye Olaf ------------------------------------------------------------------ Olaf Schneider Dr. Materna GmbH Phone: +49 231 5599-8969 Vosskuhle 37 44141 Dortmund Mail : Olaf.Schneider@Materna.de

Perldap 1.2 uses syncronous ldap calls, rather than asyncronous. If my understanding is correct, this means something along the following: With a syncronous call, I think if the call succeeds it returns all entries in one big batch to the client, and calls like nextEntry grab the next one out of client memory (this is because of LDAP syncronous calls, not PERLDAP). With asyncronous calls, I think it passes it back one at a time, so the client doesn't have to have so much memory to hold everything. Because of this, with syncronous calls, the server hits that limit prior to passing back any results, so returns an error with no results. With asyncronous calls, the server doesn't hit the limit until you ask for the 200th (whatever your limit is) record. I think this is how Communicators address book works, so it'll give you the first n matches before giving the "too many matches" error. So, if you want the first 200, you need to call stuff in API.pm to use async routines, but that's not as well documented, and I think is open for change without notice, so things may break with later versions of PerLDAP. Also, the OO calls do a _lot_ of work for you - using the async calls means you need to write a lot more code... Note that much of this is speculation on my part, from various observations. I haven't actually coded anything with the async routines to test this, so if I've misspoken on any of this, hopefully someone will correct me :-) Steve East wrote: > I'm using PerLDAP 1.2 and running into a problem with sizelimit > processing. I do the following... > > $entry = $conn->search($base, "sub", "objectclass=*", 0); > if ($conn->getErrorCode()) { > return $conn->getErrorString() unless $conn->getErrorCode() == > LDAP_SIZELIMIT_EXCEEDED; > } > if (! $entry ) { > return "no entries returned for search"; > } else { > > ...and get the "no entries returned for search" message. My server > indicates that it returned LDAP_SIZELIMIT_EXCEEDED and 200 entries. I > had assumed I would be able to access those 200 entries? Everything > works fine until I hit the sizelimit. > > Steve.

*** Bug 11099 has been marked as a duplicate of this bug. ***

Better late than ever, I fixed this in devel-branch-1_4_2, and it'll be in PerLDAP v1.5. That wasn't that bad, only 5 years in the making ... Thanks for the bug report, good idea.