[Date Prev][Date Next] [Chronological] [Thread] [Top]

Unexpected Attribute Behavior

I am implementing an OpenLDAP installation that utilizes inetOrgPerson
as the main user structure with roughly forty attributes that may be
used with each user. Of the forty attributes, I have added a custom
schema which includes 15 custom attributes. I am using MySQL 5 as the
backend via backsql.

The problem I am seeing is that for a given user, if I write values to
all 40 attributes and then read them back using an LDAP browser, three
of the attributes do not return their values.  The three attributes
are: cn, userPassword, and employeeType.

I have run slapd with the debug level of -1 (all) to capture a trace
of what happens when I read an attribute that correctly returns its
value and also a trace of reading an attribute that does not return
its value (cn, userPassword, or employeeType). Comparing the two
traces, the only appreciable difference between the two is as follows,
which is in the failing trace:

backsql_id2entry(): custom attribute list
==>backsql_get_attr_vals(): oc="inetOrgPerson" attr="employeeType" keyval=8
backsql_get_attr_vals(): error executing attribute count query 'SELECT
COUNT(*) FROM users WHERE users.id=? AND '
Return code: -1
   nativeErrCode=1064 SQLengineState=37000 msg="[MySQL][ODBC 3.51
Driver][mysqld-5.0.45-community-log]You have an error in your SQL
syntax; check the manual that corresponds to your MySQL server version
for the right syntax to use near '' at line 1"
==>backsql_get_attr_vals(): oc="inetOrgPerson" attr="objectClass" keyval=8

I also set up a MySQL error trace and ran the two attribute reads and
came up with the only appreciable difference being the SQL statement,
as above:

43 Query SELECT COUNT(*) FROM users WHERE users.id=8 AND

It appears to me that the SQL statement is not being completed for
some reason, since in the slapd trace where the attribute read is
successful, the backsql_get_attr_vals(); just prints out, number of
values in query: 1, followed by, number of values in query: 0,
followed by the actual data packets containing the value of the

I can provide additional information if needed. I was unable to find
information about this problem on the OpenLDAP site.

Kevin Burnett