Well, SQL Server has some things that are faster than VFP, and VFP has some things that are faster than SQL Server. Are you using ODBC to your VFP tables because of a specific reason? Honestly, you'd see slightly better performance if you simply used either direct access or a local view instead. You may be thinking that using ODBC makes all the processing happen on the server, but that is not true. With VFP, even through ODBC, all processing happens on the computer where the ODBC driver resides.

I'm not sure why you need a loop here, but you should always choose SCAN...ENDSCAN when looping through a VFP table or cursor. It's optimized for moving through a table record-by-record, whereas DO WHILE is not. LOCATE is fast because, from what I can see, you only need to get to one record.

I'm thinking that another strategy to try would be to move the tried=.f. records to a table on their own. That would eliminate the need to filter by "tried" making things faster. When the record is finished (tried=.t.) then you move it to your other table.

>I am using VFP tables at the back end. (My client does not have an allocated budget to acquire SQL SERVER.) My remote views access via ODBC the VFP tables. Will SQL Server yield out results much faster than accessing ODBC VFP tables?
>
>I will try out LOCATE as per your suggestion. Would a LOOP like SCAN...ENDSCAN or DO WHILE.. ENDDO (with SKIP of course) execute faster than a LOCATE?
>
>What it should do is basically have a table of around lets say 100,000 records (located at the server) and have 100 stations access it. The system or application should give out distribute the next 'available' record to whoever is 'free'. For example, when a user requests for a record, it should locate the very first available record and tag the record 'taken'. So when another user requests, it will give next the next available record, tag it as taken and so on...