>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.

Thanks for giving me feedback on this.

Hmmm ... both cursors being returned are disconnected recordsets ( I may not have mentioned that, duh ), i.e. the connection to the server is severed before the rs is returned to the client, so there should not be a "connection" back to the live data in either case. I don't know what affect that has on this. It just seems odd that the same basic rs obtained two different ways results in two different locktypes.