Thomas,

I have not yet done much of measurements of time comparison between one method or another. I am working on the "stored procedure" approach which - theoretically - should be the fastest. And honestly I am not much concerned about the speed of this procedure. This procedure will be done very infrequently so 10 seconds (or 1 minute) more or less won't make a difference. The reason I posted the question is to make sure that my "approach" will not impose unnecessary load on SQL Server and therefore upset a DBA.

Thank you for your input.


>Dmitry,
>
>while I am an confessing perf nut as well, premature optimization is
>one of the well-meant paths into self-created hell. Updating
>2000 records should not create such a problem if it happens as part of a batch-like process.
>
>Have you measured time taken and time only taken for executing the SQL-updates or even the tableupdate[s]() ?
>
>If it is a task needed to be done while entering data, it might be possible to use a multi-process/background approach,
>but that might be really complicated with the probable need for some heavy transaction levels.
>
>regards
>
>thomas
>
>>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.