William Vaughn (billvaNoSPAM@betav.com) writes:
> As cynical as this sounds, I'm with Stephen here. ADO.NET has (IMHO)
> regressed in functionality in some respects from ADO classic. I would
> embrace opening up the interface to see what it's doing so would could get
> around some of the "won't fix" or "can't fix" issues.

I'm in the opposite camp. I have difficulties to use "classic" when
speaking of old ADO. "Classic" indicates that it was actually good and
useful, but it wasn't. I also have difficulties to avoid using the word
"crap" when I talk about ADO (see, I failed this time too). Old ADO
performs too many tricks behind your back, and gets in the way to often.
I can't update that field, because it's a computed column? So what, I'm
going to update through a stored procedure. And then it the bug where
it submits a query with SET FMTONLY ON, and the procedure bombs and the
transaction is rolled back - and ADO drops this error on the floor.

On the ADO .Net and SqlClient is a very clean interface, particularly
if you stick to the basics for data access. No tricks behind your back
(well save the use of sp_executesql for parameterised queries), and
errors are caught. And if you run with FireInfoMessagesEventOnUserErrors
you can catch all errors and result sets even if they come mixed with
each other. Yes, there is an funny thing with the rowcount, but it
rarely matters.

It's almost as clean as DB-Library.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx