> Thanks Svein for your quick response! Good point about the indexes. But
> if the number of conditions grows (let's say that our memory table
> holding the QBE definition can have till 15 rows) then do you think that
> your solution, which implies a join with 15 tables, will be faster?

Yes, but only because you asked whether I THINK so. Your original suggestion made it impossible for the optimizer to avoid NATURAL on Table1, my suggestion makes it possible to avoid that if the optimizer thinks it is a good idea. Moreover, my suggestion avoids having to do a subselect with ...GROUP BY... HAVING... once for every row in Table1. I would expect this to be slower than my suggestion, but it of course depends upon a lot of things (e.g. if Table1 had ten rows and Table2 one million, things would be very different from the opposite situation with one million rows in Table1).

> No. In your above example, if we tell to DB to fetch all the 'objects'
> which have the 'FName=John' to not bring the 888.2 twice.

I'd say just use

SELECT DISTINCT T1.*

HTH,
Set
-I wonder what m. Th. is an abbreviation for?


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