On Thu, 09 Aug 2007 09:22:59 +0200 Pierangelo Masarati wrote:
Andreas 'ads' Scherbaum wrote:
The 'ldap_objectclass_list' table contains the following entries:
----- cut ----- OGo=# select * from ldap_objectclass_list; oc_map_id | objectclass -----------+--------------------- 1 | orgPerson 1 | inetOrgPerson 1 | officePerson 1 | evolutionPerson 1 | top 1 | opengroupwareentity 3 | top 3 | opengroupwareentity 4 | top 4 | domainRelatedObject (10 rows) ----- cut -----
[...]
ldap_objectclass_list is not used by back-sql; I guess you mean ldap_entry_objclasses (unless you modified the source yourself).
ldap_entry_objclasses is a view in this case and is using (among others) the ldap_objectclass_list table.
In any case, I note that the missing objectclasses, namely orgPerson and officePerson, are not standard track types. Are they defined anywhere in the schema? One of the differences between 2.2 and 2.3 is a stricter checking of the schema.
The problem seems to be:
slapd is searching the "objectClass" attributes and is getting back 6 values. Since the result is ordered by name, the first one is: evolutionPerson. This leads to the following error in the debugging log:
----- cut ----- ldap_log_execute_01.log:slapd[10928]: backsql_id2entry(opengroupwareid=10101,ou=Contacts,ou=Addressbook,dc=home): computed structuralObjectClass evolutionPerson does not match objectClass person associated to entry ----- cut -----
After removing 'evolutionPerson', 'inetOrgPerson', 'officePerson' and 'orgPerson' from oc_map_id=1, this error vanished and Thunderbird is getting data again.
More tests will follow to make sure, this really was the error.
Thank you for your help