Re: WG: how to search for custom attribute-types

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:02 PM 2002-04-15, Nick Laqua wrote:
>I don't know if this is a bug or some mistake on my side, but I can't find an error in the filter definition

It is likely not a bug.  It is more likely that the schema may
not allow the assertion you make.   I suggest you take this
to the software list.  Be sure to provide the definition of
the attribute along with the message.

Kurt

> 
>Nick
>
>        -----Ursprüngliche Nachricht----- 
>        Von: Nick Laqua 
>        Gesendet: Fr 12.04.2002 18:41 
>        An: 'openldap-software@openldap.org' 
>        Cc: 
>        Betreff: how to search for custom attribute-types
>        
>        
>
>        Hi all, 
>
>        We set up an openldap-server (2.0.23) on solaris using an oracle sql backend. We are using some custom object classes containing custom attribute types.
>
>        When issuing search statements like the one below, we are told that we are using a bad filter (logfile): 
>
>        filter=(&(objectClass=*)(smartiSupplier=10)) 
>
>        output (logfile): 
>
>        do_search 
>        ber_scanf fmt ({aiiiib) ber: 
>        ber_dump: buf=0x00167bc0 ptr=0x00167bc3 end=0x00167c19 len=86 
>          0000:  63 54 04 1b 64 63 3d 77  65 62 65 64 69 2c 64 63   cT..dc=webedi,dc 
>          0010:  3d 6e 65 77 74 72 6f 6e  2c 64 63 3d 6e 65 74 0a   =newtron,dc=net. 
>          0020:  01 02 0a 01 00 02 02 27  10 02 02 01 2c 01 01 00   .......'....,... 
>          0030:  a0 22 87 0b 6f 62 6a 65  63 74 63 6c 61 73 73 a3    "..objectclass. 
>          0040:  13 04 0e 73 6d 61 72 74  69 53 75 70 70 6c 69 65   ...smartiSupplie 
>          0050:  72 04 01 31 30 00                                  r..10. 
>        SRCH "dc=webedi,dc=newtron,dc=net" 2 0    10000 300 0 
>        begin get_filter 
>        AND 
>        begin get_filter_list 
>        begin get_filter 
>        PRESENT 
>        ber_scanf fmt (o) ber: 
>        ber_dump: buf=0x00167bc0 ptr=0x00167bf5 end=0x00167c19 len=36 
>          0000:  87 0b 6f 62 6a 65 63 74  63 6c 61 73 73 a3 13 04   ..objectclass... 
>          0010:  0e 73 6d 61 72 74 69 53  75 70 70 6c 69 65 72 04   .smartiSupplier. 
>          0020:  01 31 30 00                                        .10. 
>        end get_filter 0 
>        begin get_filter 
>        EQUALITY 
>        ber_scanf fmt ({oo}) ber: 
>        ber_dump: buf=0x00167bc0 ptr=0x00167c02 end=0x00167c19 len=23 
>          0000:  a3 13 04 0e 73 6d 61 72  74 69 53 75 70 70 6c 69   ....smartiSuppli 
>          0010:  65 72 04 01 31 30 00                               er..10. 
>        end get_filter 0 
>        end get_filter_list 
>        end get_filter 0 
>            filter: (&(objectClass=*)(badfilter)) 
>        ber_scanf fmt ({v}}) ber: 
>        ber_dump: buf=0x00167bc0 ptr=0x00167c17 end=0x00167c19 len=2 
>          0000:  30 00                                              0. 
>            attrs: 
>        conn=0 op=7 SRCH base="dc=webedi,dc=newtron,dc=net" scope=2 filter="(&(objectCla 
>        ss=*)(badfilter))" 
>
>
>
>
>        As soon as we are using well-known attributes like cn or mail, or  change the original filter like below, everything works fine:
>
>        filter=(&(objectclass=*)(smartiSupplier=*)) 
>
>        In the last case, obviously a PRESENT Filter (LDAP_FILTER_PRESENT) is used instead of an EQUALITY Filter (LDAP_FILTER_EQUALITY) and then it works although the same custom attribute is used (smartiSupplier).
>
>        any idea ? 
>
>        Nick