Michael Ströder wrote: > Howard Chu wrote: >> One crucial step in isolating the problem would be to determine if the error >> actually occurs during slapadd or slapcat. > > I revise my statement that data looks ok via LDAP. Messing up the data seems > to happen during slapadd if the LDIF is not in tree order (as already > suspected in a former posting which was not read I guess). > > Try to slapadd data1.ldif and data2.ldif in the tar.gz attached. data2.ldif is > in tree order while in data1.ldif subordinate entries come before their > superior entries (which is what slapcat sometimes produce).
Interestingly enough, my results differed from yours. Also the results differed depending on whether I slapadd'd the bare LDIF, or an LDIF with all operational attributes included. But this is now fixed in git master. Given this and the typos in back-sql it appears we should scratch 2.4.27 and push a new release. > These entries > > dn: ou=Groups,ou=schulung,dc=stroeder,dc=local > objectClass: organizationalUnit > ou: Groups > > dn: cn=slapd-1,ou=Systemkonten,ou=schulung,dc=stroeder,dc=local > cn: slapd-1 > objectClass: applicationProcess > objectClass: simpleSecurityObject > userPassword: pw_slapd1 > > get mixed into that: > > dn: ou=Groups,ou=schulung,dc=stroeder,dc=local > cn: slapd-1 > hasSubordinates: TRUE > objectClass: applicationProcess > objectClass: simpleSecurityObject > userPassword: pw_slapd1 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
