RE: OpenLDAP + Oracle 10g - ldapsearch returns no result, ldapmodify returns failure

["Pierangelo Masarati" <ando@sys-net.it>]

> Hi Pierangelo,
>
> Thanks for pointing out and thank Zhang Pu gave me a lot help also.
>
> I am able to perform ldapsearch and got the result.
>
> As next step, I added a new person object using the following
> ldif data and added without any errors on console.
>
>   [root@agito-rm root]# cat tk_0.ldif
>   dn: cn=Person0,o=sql,c=RU
>   objectClass: Person
>   cn: Person0
>   sn: A
>
>   [root@agito-rm root]# /usr/openldap/bin/ldapadd -x -D
> "cn=root,o=sql,c=RU" -w cisco -f tk_0.ldif
>   adding new entry "cn=Person0,o=sql,c=RU"
>
> But, I can not find this new entry when I performed another ldapsearch.
>
> I use SQLplus to perform "select * from ldap_entries" and found out that
> KEYVAL value for this new entry is "0".
>
> ID  DN                                 DN_RU  OC_MAP_ID  PARENT  KEYVAL
>
> 1   o=sql,c=RU                                3          0        1
> 2   cn=Mitya Kovalev,o=sql,c=RU               1          1        1
> 3   cn=Torvlobnor Puzdoy,o=sql,c=RU           1          1        2
> 4   cn=Akakiy Zinberstein,o=sql,c=RU          1          1        3
> 5   cn=Akakiy Z002,o=sql,c=RU                 1          1        4
> 6   cn=Person0,o=sql,c=RU                     1          1        0
>
>
> Shouldn't this KEYVAL be "5" ?
>
> From the 'slapd -d -1' log, looks like it passed in "0" instead of "5":
>
>    backsql_add(): executing "INSERT INTO ldap_entries
> (id,dn,oc_map_id,parent,keyval)
>                   VALUES ((select max(id) +1 from
> ldap_entries),?,?,?,?)" for dn "cn=Person0,o=sql,c=RU"
>                   for oc_map_id=1, parent_id=1, keyval=0
>
> And
>
> I also performed "select * from persons" and found out that
> the value for NAME column is 1 "blank space" for this new entry.
>
> ID  NAME
> 1   Mitya Kovalev
> 2   Torvlobnor Puzdoy
> 3   Akakiy Zinberstein
> 4   Akakiy Z002
> 5
>
>
> Could it be some sql statement problems in testdb_metadata_wo_d.sql?

As far as I remember, te test metadata assumes the CN is made of two words
separated by a blank, and the sn and the givenName are formed by splitting
this string at the blank.  As such, the ADD operation may have ended in a
broken state because you supplied an inconsistent CN.  This type of
conditions is better handled in OpenLDAP 2.3's back-sql, where failed
writes are not supposed to leave trash in the database.  But this is just
a guess, your problem may well be elsewhere.  Given the enormous amount of
(un)intended interactions between back-sql and the underlying RDBMS,
including the way the metadata is written, there may well be other
reasons.  I've never used Oracle with back-sql, so I'm not aware of any of
the above issues.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497