>Dear Cetin,
>
>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...
>
>Sincerely,
>
>Dennis

Dennis,
We were misguided with 'remote' :) Though you might fairly do it and use VFP tables in a remote view, VFP tables more fit into a 'local' view. Their location on another database or drive doesn't make them 'remote' as far as the view concerned. However I too do create them as remote views on purpose from time to time.
I have never done benchmarks between VFP and SQL server ODBC access.

scan..endscan and locate both are rushmore optimizable and would execute fast (do while..enddo is slower and in a way outdated:)

Indexing on a logical field might not be wise but in your case it sounds to be the most used one. You could create an index on taken :

index on taken tag taken


* User request
if seek(!taken, 'myTable', 'taken') and rlock('myTable')
   replace taken with .t. in 'myTable'
   * unlock in 'myTable'
else
*...
endif

Cetin