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

Good point, except that we are talking about relational data here and SQL Server in particular. Of course we could also be talking about Oracle, DB2, etc. As for other data stores like Active Directory, etc, that is another issue.


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

Obviously, in this forum, there are things I could say, but that would violate several standing NDA's I have. Lets suffice it to say there is a lot of pain out there. Again, for simple tasks, you might be able to get by with updating through a recordset. However, when it starts to get moderatly complex things start to break down.

Further, I don't really care how folks may be doing something. The issue is whether they are doing it the best or most correct way. As the saying goes, practice does not make perfect...perfect practice makes perfect...