RE: Strange(?) back-sql behavior

[Rajen Damani <rdamani@timesten.com>]

A fix for query with 1=0 has been checked into development branch.  With
this fix it does not make such query.  However, it is not available in
release branch.

Rajen Damani
TimesTen Performance Software
http://www.timesten.com 

> -----Original Message-----
> From: Ranko Zivojnovic [mailto:ranko@spidernet.net]
> Sent: Tuesday, November 27, 2001 9:23 AM
> To: openldap-software@OpenLDAP.org
> Subject: Strange(?) back-sql behavior
> 
> 
> Greetings!
> 
> I have setup an LDAP server with MSSQL as a backend via EasySoft OOB.
> 
> ------------------------------
> Question 1:
> ------------------------------
> Debugging shows that SQL backend is generating some strange 
> queries like:
> 
> <==backsql_srch_query()
> Constructed query: SELECT DISTINCT ldap_entries.id,PERSON.ID, 'top' AS
> objectClass, ldap_entries.dn AS dn FROM ldap_entries,DIALUP WHERE
> PERSON.ID=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND
> ldap_entries.parent=? AND (('top'='organizationalPerson') AND  1=0 )
> _SQLprepare(): enabling MS SQL Server default result set workaround
> 
> 
> 'top'='organizationalPerson' is by definition FALSE.
> 1=0 was never and will never be the case.
> Having the above two lines in mind, why does the backend go 
> and executes
> this query on the SQL server at all? Since constructed query 
> has two string
> literals and two integer values in an equation, shouldn't 
> there be some sort
> of internal optimization or something like pre-check or 
> pre-comparison in
> the code? These unnecessary SQL queries greatly hamper the 
> response time.
> 
> ------------------------------
> Question 2:
> ------------------------------
> Table 'ldap_entry_objclasses' is there in order to add additional
> 'objectClass'-es to the result. SO far its OK as long as I do 
> not use those
> classes in my LDAP searches. When I try to search LDAP and 
> include in the
> query as one of the filter parameters objectClass (OC) to 
> equal one of the
> OC-s in the mentioned table, it appears that the backend does 
> NOT utilize
> this table in its search against the database. Why? Is this a 
> bug or is
> there another way of having multiple OC's in a resultset?
> 
> Thanks and best regards,
> 
> Ranko
> 
> --
> Ranko Zivojnovic,
> NOC Manager              ranko@spidernet.net
> Network Operations Center
> 
> Spidernet Services Ltd., Tel: +357 2 844844
> Nicosia, Cyprus          FAX: +357 2 669470
> 
>