>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.

No argument there, assuming the data are sitting on a backend server. Allowing access to data only via stored procs has been a "best practice" long before ADO and SQL Server came along.

> 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.

Not all data live on a backend server, and stored procs may not be available for use. ADO lets you get to Jet, Exchange, Active Directory Services, and loads of other data stores that you have to get to via recordsets and not stored procs. The way I read your original message, the implication was that there was an inherent flaw with recordsets that would lead to data corruption or data loss. At least that's how I define unreliable.

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

It's not how a large number of real world users are doing it. Sure, it can be argued that this is how they should be doing it. But lots of folks are using recordsets for update/insert/delete, and it doesn't seem that they're suffering from a lack of reliability in recordsets.