Tim

Much time ago in the dim and distant land of DBISAM multiple ORs were better than IN. I seem to recall that changed.

Which is the better in ElevateDB, or are they pretty much the same? eg if one form meant less work for the sql preparation I'll generate code for that form.

Roy Lambert

ps


I've currently got things set up to generate INs

Roy Lambert

Hi Roy

I have no measurements available, but a long time ago I used to work
with Informix and IN was known to be very slow.  I found the same in
DBIsam.
As a result I have always tried to avoid IN unless with a small set of
values and 'modest' row numbers.
I don't know how IN is implemented so I can't explain.
I imagine Tim will pop up some day to enlighten us.
Maybe someone can find it in the source...

Malcolm

Roy,

<< Much time ago in the dim and distant land of DBISAM multiple ORs were
better than IN. I seem to recall that changed. >>

You'd have to point me to where it was said that using ORs were faster than
IN.

<< Which is the better in ElevateDB, or are they pretty much the same? eg if
one form meant less work for the sql preparation I'll generate code for that
form. >>

IN will be ever-so-slightly faster due to the fact that it has a more
efficient expression structure, but that's about it.

Tim Young
Elevate Software
www.elevatesoft.com

Tim

>You'd have to point me to where it was said that using ORs were faster than
>IN.

If I can ever think up how to query my newsgroup archive to find it I will. Just entering OR and IN as search terms is not liable to be productive

>IN will be ever-so-slightly faster due to the fact that it has a more
>efficient expression structure, but that's about it.

Thanks - especially since its easier to build an IN

Roy

Tim Young [Elevate Software] wrote:

> IN will be ever-so-slightly faster due to the fact that it has a more
> efficient expression structure, but that's about it.
>
That's good to know.  I have erased my bias against IN.