Hi Fabio,

>>Actually it is 9 (maximum of 9 EXIST clauses in VFP8).

>You have other two table for the join, and 7 max EXISTS/NOT EXISTS.

It has nothing to do with the number of tables involved in the query, but the number of joins. There is a limit of 9 joins, Further you can replace a INNER JOIN very easily with a FROM Table1, Table2 WHERE Table1.pk = Table2.fk. This leave a maximum of 9 EXISTS clauses.

>>I think in these extreme cases you have to look really well about performance penalties becauses you're talking about a >lot of potential records and hardly can avoid full table scans. Note that your solution is also limited (to 24 items) >unless you choose to join it with a custom cursor.
>
>Yes, but i have not indicated the solution as the better solution for the general case.
>
>>There is no need to be picky, I'm just trying to be constructive.

>Sorry, but the impression has ahother.

I'm sorry, if I did give you the impression. It was not meant that way. Just wanting to be constructive. That's all.

>If you remove the hypothesis that table on exists() have a index for the join field,
>then VFP must build 1,2,...7 temporary index, and for large table this can to be very time consuming.

It would not be logical to have a column called fkey or pkey and not have an index on it (for at least RI). The assumption of having a key there would be very normal if you asked me.

About the index, I'm not sure if it needs since it is about the same columns for the same table in each exists, theoretically it only needs to add one index. I guess it depends on the query optimizer though.

>If you not put constraint hypothesis, the discussion it can go ahead to the infinite.
>Best general solution, without hypothesis, not exist.

Not sure what you're telling me here.

Walter,