>I wonder why so many folks use SEEK at all these days. Between LOCATE and SQL and SCAN (none of which require a SET ORDER), why SEEK at all? Just curious, in case I'm missing something. :)

Steve,

I can't speak for anyone else, but my situation may apply. I have a number of systems that require that the table not be normalized. There are two reasons for this. First, there are a large number of summary reports connected with these systems. All of these are generated by queries. So there would be a performance issue. That aside, however, there is another even more valid reason for non-normalized tables.

These tables track production and measure efficiency against standards. The standards, however, are not static. They can, do change, often on a quarterly basis. The standard against which production has to be measured, though, has to be the current standard. So this is retrieved using a SEEK.

I should point out, however, that when the system is moved to SQL Server, it'll use probably a parameterized remote view to retrieve this information. Currently, the data is stored in Fox tables.