>>>Yes, that "theory" has now changed - actually since almost 2 years, I think. You must read the threads here more carefully < s >
>>
>>I guess I missed those ones.
>>
>>>While it is general concensus that the situation has NOT changed over the years, I remain a doubter on that specific issue. That is, I feel that it HAS TO HAVE CHANGED somewhere along the line.
>>>
>>>In any case, DELETED() TAG is BAD FORM now with DELETED set ON and especially with bigger tables.
>>
>>Well, in my case, it's not an issue of big tables. 3000 records with INNER JOIN shouldn't be that much of an issue.
>
>Michel,
>
>Another idea:
>
>If the data is for a report, it often helps to divide a multi-table query into several queries - select one or two tables first, and then add one table at a time.
>
>Hilmar.

I agree. I recently had a situation, where I need to join three tables. Craig Bernston pointed me to his site, where I found in an article, that this query never could be fully optimized. The original query took about 2+ minutes to finish. It was very slow. So, I divided this query by two parts with indexing temp result and the whole process now takes ~20-30 sec. Still slow, but much better, than before. At the same time I was perfoming couple of tests with set deleted on/off and with/without deleted tag. I found, that perfomance is better without deleted tag. But we delayed this issue for now...
Check the recent threads...