[Date Prev][Date Next]
Re: Unexpected Attribute Behavior
<quote who="Kevin Burnett">
> slapd version: 2.3.32
> on RHEL4 i386
The usual story applies here, please try with our latest version and get
back to us.
> On Nov 11, 2007 1:17 PM, Gavin Henry <firstname.lastname@example.org> wrote:
>> Kevin Burnett wrote:
>> > 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()
>> > backsql_id2entry(): custom attribute list
>> > ==>backsql_get_attr_vals(): oc="inetOrgPerson" attr="employeeType"
>> > 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"
>> > 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
>> > attribute.
>> > I can provide additional information if needed. I was unable to find
>> > information about this problem on the OpenLDAP site.
>> > Kevin Burnett
>> You don't say what slapd version you are using. Please provide the
>> Kind Regards,
>> Gavin Henry.
>> OpenLDAP Engineering Team.
>> E ghenry@OpenLDAP.org
>> Community developed LDAP software.