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

Re: Unexpected Attribute Behavior

Kevin Burnett wrote:

> 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" 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

This is clearly incorrect.  However, it is not easy to determine where
it fails without looking at your back-sql metadata.  I suspect that
attribute's metadata provides a non-NULL but empty join_where value.

> 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.

To provide even more extensive logging, you can rebuild back-sql after
manually defining BACKSQL_TRACE in back-sql.h; this is really a
developers'-only option, so you should not use it in production, as the
logging is really verbose.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it