>I always find Xbase commands faster than Sql(statement) commands.
I'd agree partly, but xBase is not always much faster.

>Also i would like to know best prsctices where to use what ??
Well, as others already said: An SQL statement doing even complex
things is easier to do than complex (eg nested) scan loops etc.

So SQL gives you better maintainability and it's also portable
to other databases, at least much better than xBase code.

With mass data processing sql has it's advantages in coding
queries in quite a 'natural language', often easier to understand
by other programmers compared to a piece of xbase code.

SQL benefits much of rushmore optimization. But that optimization
is not needed if you initially know which indexes to use and code that
in xBase style. That way you can win at least the time rushmore needs
to find out how to optimize a query with the xBase equivalent of that
same query.

But the advantage of SQL is, you can dynamically genereate queries,
which gives you much more flexibility than xBase loops can give you.
It would at least be much harder to flexibly add another table and
nest in another loop compared to simply add the table name to the
FROM clause and a JOIN condition or corresponding WHERE condition.
That again is big points pro SQL and it's maintainability.

xBase is always nice when doing something on single records or
just a few bunch of related records. The performance advantages
you can get out of SET KEY and RELATIONs are often overseen by
people prefering SQL.

And even with mass data xBase can be very effective. Just a
little example: Searching orders without any orderitems.

open database (_samples+"data\testdata.dbc")
use orderitems in 0 order by order_id
use orders in 0
set relation to order_id into orditems additive
browse for eof("orditems")

The "resultset" is empty, but that's not the point. I wonder if
that could be done faster with any SQL, even if the testdata.dbc
would have more data in it.

Bye, Olaf.