I agree. Especially when creating stored procedures. In VFP code (that works with SQL Server tables) I can still use a lot of xBase language but in stored procedures it has to be all SQL commands.

>The hardest transition from VFP to a server back end is to start thinking "data sets" not one row at a time.
>
>>Thank you. This will be a challenge for me to create such a stored procedure. I am sure it is not that complicated but I have created only very simple stored procedures. But maybe it is time to learn.
>>
>>>It is better to do the processing on the server if possible using a stored procedure.
>>>
>>>>Hi,
>>>>
>>>>I am trying to decide on the better approach of processing/updating many rows of a table. Here is the brief description.
>>>>
>>>>A table of about 2000 rows has to be processed where for each row the program has to recalculate certain amounts (based on other tables) and update 2 columns. I am using Cursor Adapter as a method of getting/setting SQL Server tables. From the stand-point of efficiency of SQL Server, is it better to get all records/rows of the table, scan thorugh all rows of the cursor, update the values, and then do TableUpdate() for all rows? Or process one row at a time and call TableUpdate() after each row is processed (columns updated).
>>>>
>>>>TIA for any input.