Strange(?) back-sql behavior

["Ranko Zivojnovic" <ranko@spidernet.net>]

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