>What do you see as a downside of this approach?

Too roundabout... you're creating a xml somewhere, then passing that xml with a SP call to SQL, then in SQL extracting the names and values into variables, then composing a statement which would update it... except you can't compose the update statement, it has to be compiled, so you can't pass a variable number of parameters unless you're sure the missing ones will be null... too many steps.

I'd write that as a textmerge to build the update statement with exactly the number of fields you have, dynamically and send it straight to SQL. In metacode,

lcComma=""
c=""
for each oPair in oValues
   c=c+ lcComma+ opair.name+"="+opair.value  && note that here we need some conversion to string
   lcComma=", "
endfor
text to lcSql noshow textmerge
update <<lcTable>> set <<c>> where pkField=?nPkValue
endtext
nRet=sqlexec(h, lcsql)

where oValues is a collection of objects containing name/value pairs (but you may have them in an array or other storage, so the loop would look differently). The loop could also skip those missing values as well.

Alternately, I'd create an empty object (say, oE) and add properties to it as we go, so the syntax of it would be simpler and no need to convert values into string, VFP+ODBC driver would take care of that:

oE=createobject("empty")
lcComma=""
c=""
for each oPair in oValues
   addproperty(oE, oPair.name, oPair.value)
   c=c+ lcComma+ opair.name+"=?oE."+opair.name
   lcComma=", "
endfor
text to lcSql noshow textmerge
update <<lcTable>> set <<c>> where pkField=?nPkValue
endtext
nRet=sqlexec(h, lcsql)

Now if you so strongly prefer stored procedures, enjoy them...