Ah, sorry, I misunderstood and see now what you meant.
I won't be using parameters for where conditions, so I think for me then
like and starting with in this particular situation will be the same.
Thanks again for explaining.

RBS

2011/2/2 Svein Erling Tysv�r <svein.erling.tysvaer@...>

>
>
> >Thanks for that thorough information.
> >So if I get you right no difference in normal direct SQL, but there can be
> a
> >difference in stored procedures?
>
> No, that is not what I said. I said there can be a difference if you use
> parameters as opposed to constants. So, to use Delphi syntax (at least if
> used with IBO):
>
> MyCursor.SQL.Add('select * from MyTable where field1 starting ''Z''');
> MyCursor.Prepare;
>
> Should get the same plan as:
>
> MyCursor.SQL.Add('select * from MyTable where field1 like ''Z%''');
> MyCursor.Prepare;
>
> Whereas
>
> MyCursor.SQL.Add('select * from MyTable where field1 starting :Param1');
> MyCursor.Prepare;
> MyCursor.ParamByName(Param1).AsString:='Z'
>
> Is very different from
>
> MyCursor.SQL.Add('select * from MyTable where field1 like :Param1');
> MyCursor.Prepare;
> MyCursor.ParamByName(Param1).AsString:='Z%'
>
> The point is that the plan is generated at prepare time, and at that point
> in time, the last SQL doesn't know whether it can use an index or not (i.e.
> it doesn't know whether the parameter will be Z% (which can use an index) or
> %Z (which cannot)). LIKE gives the programmer more freedom than STARTING
> WITH, but at the cost of limiting the choices available to the optimizer.
>
> HTH,
> Set
>
>
>

[Non-text portions of this message have been removed]