Full_Name: David Stults Version: 2.4.23 OS: CentOS 5.5 URL: Submission from: (NULL) (64.122.164.12) When executing the add_proc SQL query, back-sql claims to provide the attributes in a particular order, but reality is reversed: slapd log: backsql_add_attr("radiuslogin=xyzzy2,ou=Dialup,ou=External,o=Integra"): executing "UPDATE radiusaccount SET radiuslogin=? WHERE id=?" val[0], id=1411 MySQL log: 173 Query UPDATE radiusaccount SET radiuslogin=1411 WHERE id='xyzzy2'
Note that this appears to be a logging issue rather than a functional one. The parameter order changes according to the param_order field, but the slapd log always indicates the order as if param_order=0 On Aug 26, 2010, at 11:38 AM, <openldap-its@OpenLDAP.org> <openldap-its@OpenLDAP.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6631. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its@openldap.org with (ITS#6631) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6631) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6631 > > Please remember to retain your issue tracking number (ITS#6631) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >
> slapd log: > backsql_add_attr("radiuslogin=xyzzy2,ou=Dialup,ou=External,o=Integra"): > executing "UPDATE radiusaccount SET radiuslogin=? WHERE id=?" val[0], id=1411 > > MySQL log: > 173 Query UPDATE radiusaccount SET radiuslogin=1411 WHERE id='xyzzy2' > Note that this appears to be a logging issue rather than a functional one. > = > The parameter order changes according to the param_order field, but the > sl= > apd log always indicates the order as if param_order=3D0 I'm not sure I understand this report. Can you please make the example more esplicative? Also, please note that "id" in the update procedure is the name of a specific field in the RDBMS, while "id" in slapd's log is a generic name for the key that is being used. The name coincidence is purely incidental. Also, that portion of the code has been recently modified (to allow 64-bit integer keys); could you test with back-sql code from HEAD? It should build and work straight with 2.3.43 code. Thanks, p.
changed state Open to Feedback
> Also, that portion of the code has been recently modified (to allow 64-bit > integer keys); could you test with back-sql code from HEAD? It should > build and work straight with 2.3.43 code. I need to partly amend myself: that improvement requires long long parsing capabilities that were added to liblutil, so you'll probably be better off pulling the entire HEAD from the CVS to test it. p.
Hello, This ITS is being closed due to a lack of feedback. If you continue to encounter this issue with a current release of OpenLDAP, please file a new issue report, providing the additional details that were requested in this ITS. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
changed state Feedback to Closed