>>>I called MS on the join speed issue back on VFP 3.0. The issue is when you perform a join, EVERY record is checked against EVERY record in EVERY database involved in the join. If you are checking against more than 2 databases, the join gets longer expodentially be each additional database. I still code all my join/datacross checking functions because they are ALWAYS faster than a join. My .02
>>
>>
>>That's not really true. Rushmore will use any index available and will only look at each record when no index matches the condition AND Rushmore determines that it doesn't need to build a temporary index. See the Rushmore document on my web page for more information.
>
>My point exactly. If you know what you want, make sure the indexes exist, and transverse the data once, this willl always be faster. Generating Rushmore temp indexes takes time, selecting which indexs to use, etc. I'll still checkout the Rushmore doc, but I don't see how anything having to go through logic to find an effective way to do something is going to be faster than someone coding what they know they want to do. My .02

If you know exactly what you want it may be faster to do it yourself. However, one line of code (SQL SELECT) may execute faster than several lines (ROLL YOUR OWN).