Hi Suhas,

A little bug in your code: The cursor test has no field t1 to create an index on.

I'd say you could even do it a little faster with the xBase code, as you can rely on scanning through unique timestamps, as the unique index is set. So you needn't scan for !seek(), but simply scan...endscan and rely on the timestamps you collect on the way to be unique. So this should work too:

m.t1 = seconds()
use bhav_data in 0 order tq
create cursor test(timestamp c(20))
select bhav_data
scan
insert into test values(bhav_data.timestamp)
endscan

select test
locate && to set the record pointer to 1 as to compare case of sql
?seconds() - m.t1

SQL rushmore optimization will not optimize DISTINCT with the unique index. It only optimizes filter and join conditions.

You may have a problem though, if you have SET DELETED ON, have the record for a certain timestamp that is contained in the index marked Deleted() but still other undeleted records with that timestamp. Then sql would find that value, the scan over the unique index wouldn't.

Towards the general question SQL vs xBase:
It's hard to draw the line, where SQL is faster and where xBase is faster. Rule of Thumb is, that mass data access/processing can be done faster with sql, processing of single/few records speaks for xBase. You show a case that would even work with more data, but only because of the lack of the SQL engine to not optimize DISTINCT with a unique index. See SYS(3054) in the help for more information.

Bye, Olaf.