>>>>My tests showed, much to my surprise, that LIKE was not optimized.
>>>
>>>Our tests showed partial optimization for LIKE clause and full optimization for =. Now, I thought I read somewhere that VFP 9 has full optimizable LIKE, but I don't remember, where I read it, so do not know, if it's true.
>>>
>>>I used SET ANSI OFF in order to use =, but I belive, it makes now everything not generic, since other back-ends use ANSI ON. So, it looks like I have to use LIKE clause if I want to easy switch back-end.
>>>
>>>What do you think about this?
>>>
>>>Thanks in advance.
>>
>>Sorry for Jump in.
>>
>>With SET ANSI OFF and = you write a two side LIKE 'item%' comparison,
>>

>>expression1=expression2
>>is
>>expression1 LIKE 'expression2%' OR expression2 LIKE 'expression1%'
>>

>>and it is impossible optimize it without a key index with variable lenght.
>>
>>Before VFP9 in many situations VFP it optimized the query and it could return to you wrong results.
>>
>>On VFP the LIKE 'expr%' can run with a full index filtering,
>>but exists two issues:
>>1. on VFP don't exists a escape character,
>>then for search a '%' or a '_' the LIKE is useless
>>2. on all backends the LIKE comparison uses the context Collate order,
>>as == ( ANSI ON VFP comparison),
>>but on VFP the LIKE uses MACHINE COLLATE,
>>and without a MACHINE index the optimization is not full.
>>
>>Fabio
>
>Fabio,
>
>Thanks for your reply. I am creating a search form and I implemented it using = operator with SET ANSI OFF. But I want to write it the universal way (keeping in mind the possibility of other back-end), so I will need to switch to LIKE operator... I am afraid I will have performance penalty...
>
>BTW, unrelated small question: I have a container based phone control. I set a property lNoExtension, and if this property is set to true I want to remove txtExtension and its label. I wrote it using RemoveObject, but I'm thinking, it would be better to return .f. from the Init of these controls instead. What do you think? Or it's such a minor thing I should not even put my mind into...

Hi Nadya,
For this last every way is different.
You have 3 ways:

* 1. add it like a static member and
* on txtExtension and label Init
- RETURN !this.Parent.lNoExtension

* 2. RemoveObject dynamically
* on txtExtension and label Init

* after you can show or RemoveObjects()
 Container.RemoveObject('txtExtension') 
 Container.RemoveObject('Label')

* 3. add it dynamically
 Container.AddObject('txtExtension'
 Container.AddObject('Label'

I thinks Init .F. is faster,
but, if % of Init false is > XX% ),
add, with AddObject,
the txtExtension is more faster in Average.

The fundamental is not speed, but at design level.
The difference 1. to 2. is a design difference:
with 1. you remove the Extension definitively
with 2. or 3. you can remove/add the Extension
with a interactive choice ( by the customer for example ).

Fabio