<<
So your point is that everything can't be controlled through stored procs if recordsets are used. Okay, I'll agree that this is a valid point. However, that does not support the point that recordsets are unreliable.
<<

The most reliable way to update/create/delete data is via stored procs. Recordsets do not support stored procs. Therefore, recordsets do not present the most reliable way to update/create/delete data. For very simple work, yes, I suppose Recordsets will do. From a security standpoint however, it means you have to cede control to client-side rendered SQL. For many, this will not do. For complex models however, recordsets, at least from a data update/create/delete standpoint, break down.



>
No, it's not "pretty much agreed upon" by those that "actually do the work". I used to support this technology, speaking with those outside the ivory tower every single day. I'm well aware of what's being done in the real world.
>

It is pretty much agreed upon by those who write in VBPJ and SQL Server Magazine..


>You're probably right. Instead of debating the technical points, you've decided to turn it into a discussion of who does what for a living. Sorry, I've got a busy weekend coming up, and I don't have time to play such games.
>

No game on this front...


>
You mean the very folks that I supported and spoke with on a day-to-day basis? Yeah, they always called just to chat, never to report problems or limitations with the technology. So, yup, I'd know nothing about that.
>

Mike, your post to me, starting this dialog brought up this issue. To me, it was a bit defensive.

>
Why offline? I'm sure plenty of folks could benefit from further discussion. When you're ready to discuss the technical aspects of this, let me know.
<


I have already laid out the technical aspects of the argument... See my opening paragraph in this post..