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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > --------------------------------------- > > >
