Thomas,
Thank you very much for your input.

>Dmitry,
>
>>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.
>
>That could be a totally different ball game.
>First of all, you are asking the wrong people: we can only guess,
>but your DBA has at least educated/well honed gut reactions ;-)
>
>Second: assuming the calculation to arrive at the 2*2000 new values involves nontrivial computation
> (1H to read the doc, 2H to get a picture with some scribbles and 3 days to discuss all
> the logical errors in the doc from version 1 to a version you can implement as biz code:
> if done in SQL need some stage/temp tables and/or many joins and lengty case statements)
>
>from a pure server cost standpoint it will ALWAYS be better to calc the update values client side
>incurring the *calc* cost NOT at the server, then pump your data via bulk insert into SQL server cursor
>and run a simple update org set a=bulk.a, b=bulk.b from bulk join org on org.pk=bulk.pk
>
>If the server is REALLY red-lined the DBA he might be happy if you run single updates from
>the client side about 10 per second: if such a measure is needed, walk away from the job
>as they must be nearly broke ;-)
>
>But for just updating 2000 recs I expect the DBA to be glad for the coffee
>and just shrug on the server cost aspect...
>
>You can still implement the client side in vfp SQL to keep an option to port
>into a SPROC with small effort.
>
>regards
>
>thomas