John,

>Well...I have done a lot more than just test. I have production apps, big production apps I might add, that implement ADO. < s >...

Yawn... why the need to regularly talk about the big projects you have done? Do you think that will lend more weight to your arguments? Why the need to try to insinuate that MikeS does not have sufficient real-world experience to comment on this? Sounds like you don't want him to go into details that might call into question your points. Better to just debate the merits than tear down the qualifications of the debater.

>It is really about recordsets in general. Recordsets are good for presenting data. As for updating data/creating data, that is another story. With SQL Server, you can create a recordset via a stored proc - and that is good. However, when it comes time to update data, you cannot point your recordsets to a command object that is in turn, references an update proc.

So if I'm reading this correctly, the real story is that you're talking about a limitation or trade-off that was required by the approach you took with DataClas, which you naturally believe to be the right approach.

>Updates through a recordset essentially represent client-side rendered SQL Updates or SQL Inserts. By going this route, you cut yourself off from the granularity of control that one really requires.

So it's an architecture issue more than a technology issue.

>It is pretty much agreed upon by those that "actually do the work" that updates though recordsets is not only a bad idea, it does not work reliably.

And who are those people? Names, please. I'm sure we all are eager to hear who is actually doing all of the work out there. Are you SURE they all agree? Names, please. Documentation of where they have all "pretty much agreed"?

>Mike, you really don't want to to down the ADO/OLE-DB road with me.

< Gag > Why the need to intimidate? You obviously *think* that you are the ADO/OLE-DB expert, and that's your right to think that. Please stop trying to control the open debate of the issues here.

>If you would like to talk offline about this, I would be more than happy to do so.

Why offline? Let the issues be sounded out publicly. If Mike knows some things that can elighten us, why try to shut it down?

Just keeping it real, John.