>>I've lent out my ADO book, but that behavior makes sense because a command object is simply executing a command, with no back link to the data source.
>
>I don't quite follow you here. Both methods return an ADO clientside recordset that has a declared locktype of adLockBatchOptimistic. Are you saying that without a back link to the data source, the locktype has to be coerced to adReadOnly? Can you explain why that would be?
>
>The reason I was using a Command object is to get the better performance available thru a SP. Seems a little funny for a limitation like this to be imposed.

I don't know enough of the internal workings of the objects to say this with force...but I believe a recordset object will have a "reference" to it's source and would thus be able to perform an update. The command object simply performs the operation and is done. No reference back to the data source. Compound this with the fact that you are running against an SP - which is also a one-way trip - and your client-side cursor will end up being forced to read-only.

A similar thing happens in VFP when you do a SQLEXEC to a cursor. That cursor is also read-only.

Anyone else? If this is wrong, feel free to jump in...meanwhile I'm going to do some testing to make sure.