Having gone through this thread on clustered indexes, it's clear a few things need to be cleared up.

What is a clustered index?
This is a SQL Server feature that physically sorts the data via the index. Since it's a physical sort, there can only be one of these for a given table. Data is physically sorted by SQL Server real time automatically. Internal storage mechanisms are built and optimised for this behaviour.

Why do you need a clustered index?
It permits the fastest retrieval of certain types of queries. If most queries use the primary key then this calls for a clustered index. Other indexes in SQL Server use the clustered index as the final search. IOW, during a query that requires a non clustered index, the conditions for that query are met and the final component of the query is to use the clustered index to actually retreive the data. Indexing in SQL server is much more complex than in VFP. SQL Server may decide to not use the indexes and do a full table scan if the index is poorly constructed (indexing on columns that have only a few unique values) or if the query uses sums without where conditions and so on.

Clustered indexes in SQL server are bread and butter and used all the time. That said, they are not mandatory. It's important you understand what indexes are doing before adding them. SQL Server 2000 is highly optimized for index use.

Can VFP benefit from clustered indexes?
The answer is yes and no. If you are joining data on primary keys, which is likely a majority of the time, query times will be dramatically reduced if
the data is physically sorted on the primary key. I published this information many years ago in FPA. It's worth doing on very large data sets.

Here's the "NO" part of the answer. Clustered indexing is not possible due to the internal storage mechanism of VFP data. So you have to physically sort your data every once in while to achieve the same results.

Hope this helps,

Val Matison
Matison Information Architects