>
I've only supported and extensively tested such recordsets on a professional level. I guess that means I'm just a poseur, but I hope I can answer any questions that might arise on the subject.
<

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


<<
I find it to be quite reliable, if done properly. What, specifically, do you find to be "unreliable" about heirarchical (sic) recordsets?
<<

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.

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.

What we do is use ADO recordsets to present and hold data on the client. However, when it comes to updating/creating data, we marshal data from the recordset to a command object.

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.

Mike, you really don't want to to down the ADO/OLE-DB road with me. And yes, your employer designation is duly noted. The bottom line, the folks that really know the most about ADO, really understand its limitations are the consultants that don't work at MS. I am talking about the folks that actually "do the real work"...

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

< JVP >