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