>>>I am refactoring my application to make it work with either VFP or SQL Server. One of the procedures involves processing every record (in VFP) or row (in SQL Server) of a table. This is not a frequently used procedure, maybe once or a couple of times a year. The table could be up to 10,000 rows (in reality I don't think I have a customer that has this many records but I believe this would be a possible upset limit).
>>>
>>>In VFP things are pretty simple: you open the table (with USE) and process the records.
>>>
>>>One approach of SQL Server I am contemplating is to retrieve all rows of this table into a cursor (using SQLEXEC) and then process each row of the cursor and update each row of the table one at a time, as the cursor being updated. My question is the following: is this a reasonable (practical) approach for an application with SQL Server? My main concern is that I will be pulling 10,000 rows from the SQL Server database with one shot. Will this slow down the SQL Server or can cause problems for other databases/applications? Keep in mind that I am not concerned about the time it would take as this is very infrequent procedure.
>>>
>>>Thank you in advance for any suggestions.
>>
>>Why not make a SP that would do the job for you?
>
>The process involves some business rules. Business rules are different for different customers. Therefore, I prefer to do this procedure in the biz tier of the application.

I see. I doubt that you could slow down SQL Server (if you have right indexes). Now I could get 4000 records for less than a second (LAN). Never tested it in WAN.
Also all depends how big is the record size 10 000 * 100 bites record size is nothing, but 10 000 with 8 000 bites record size is more almost 80MB transfer.
But you should test the worst scenario you can thing of, just to be sure.