Hey John,
>The system I wrote in VFP uses the Scan and Local engine to walk small to medium datasets (10,000 - 500,000) to find transactional anomalies (credit debit card improper card usage (Fraud) and even with what is new in SQL server 2005 it is still to hard to do.

Very interesting what you say here. From what I comprehend I think SQL is still very weak in walking tables - the working habit of office workers.

Those mundane forms where they render data in a grid from a local cursor and the details from the selected row beneath it gives me the chuckle, especially when multiple changed records need to be updated on the server. Do you know any company where only one person works single user on the db? Now show me the clerk who handles this gracefully if multiple updates fail...

I watched a lot of webcasts with SQL Server (2005) guru Kim Tripp recently. If a SQL server gets hit hard it´s all about performance and IOs (input / output ops).

************
My POINT is: If you want to SCAN / walk a table without buffering the data locally, for every SELECT the engine must walk the whole tree to the data.

What I´ve been wondering since I´m into SQL Server is:
Couldn´t the server keep the state, say

SELECT * FROM authors WHERE au_id=@au_id WITH KEEP_STATE

so I could SKIP to the next (or prev) easily with a lot less of IOs.
************
Maybe with my limited knowledge I´ve ridiculed myself now big time, but with your message I could get rid of this.
Thanks for any reasonable answers to this.
G