It is important to note that a recordset actually uses a command object to do the updating. A recordset has an ActiveCommand property that points to it's Command Object. When a recordset fetches records, it uses a Command Object to do this work as well. When you rely on the recordset itself to broker updates, you are ceding control to some behind the scenes work. Also, if you rely on the recordset as your primary interface, you cannot work with stored procs. With VFP data, this is all a moot point. For small apps, you may not have problems. On large scale work, the problems tend to arise rather quickly...


>Sorry, I should have clipped more from your response to Travis. You said:
>
>"The best use of recordsets is for passing data around and presenting data....period. As a mechanism for updating data, in a word, they suck. There are too many things under the covers that cause too many problems. In reality, whenever you reate an ADO recordset, a Command Object is implicitly created. It is far better to make direct use of the Command Object."
>
>I was particularly interested in the part about using recordsets for updating data. I've got numerous apps using disconnected ADO recordsets for updating data, and I'm curious as to what kinds of problems I can anticipate. So far, I haven't noticed anything unusual but my apps don't live in a stressful environment. Thanks for any advice (and sorry for the confusion).
>
>Bob
>
>
>
>
>>Hi Bob...
>>
>>To be honest, I don't understand your question. Could you clarify it up a bit?
>>
>>Thanks...
>>
>>
>>>SNIP
>>>
>>>"There are too many things under the covers that cause too many problems."
>>>
>>>You have my undivided attention! I have numerous applications where I'm passing a disconnected recordset to the UI, updating it, and returning it to backend via a middle tier. I use stored procedures in many case but not in all. Just how do these "problems" manifest themselves?
>>>
>>>Bob