Pierangelo,
You suggested, "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."
I wanted to thank you for this insight because this is exactly what my problem was. In the ldap_attr_mappings table, for the three attributes in question, the join_where column was not set to Null. Since I do not currently need a join syntax, I simply set the three values to Null. The attributes now return their values correctly.
Thanks for making a great product, OpenLDAP.
Kevin Burnett
On Nov 15, 2007 4:08 AM, Pierangelo Masarati ando@sys-net.it wrote:
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.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it