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