[Date Prev][Date Next]
Re: Unexpected Attribute Behavior
You suggested, "This is clearly incorrect. However, it is not easy to
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.
On Nov 15, 2007 4:08 AM, Pierangelo Masarati <email@example.com> 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.
> 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: firstname.lastname@example.org