|
|
Posted by William Vaughn on 09/03/07 16:35
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.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant, Dad, Grandpa
Microsoft MVP
INETA Speaker
www.betav.com
www.betav.com/blog/billva
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
-----------------------------------------------------------------------------------------------------------------------
"Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom> wrote in message
news:uPVphpj7HHA.1164@TK2MSFTNGP02.phx.gbl...
>>> Can you get classic ADO and SQLOLEDB in combination not to do that?
>>
>> Yes, don't use it.
>>
>> Seriously, it's is very difficult to get ADO only what it supposed to
>> and not a lot more.
>
> Well it is a stupid state of affairs that Microsoft invest 7 years in
> ADO - and even now we dont fully know what it does - there is a heck of a
> lot undocumented or poorly documented.
>
> I am amazingly tired of playing the game, "ooohh, you have discovered some
> flaws in our existing mature technology - why dont you shift to our brand
> technology which does not have that flaw?".
> Because it is only a matter of time before someone discovers that ADO.NET
> has flaws and how long will it be before MS declares ADO.NET and .NET
> legacy, they are bored with it, and start creating other new "cool
> technology"? And then we are back to the same cycle. It is a crap state of
> affairs.
>
> There are limited ways of accessing databases - rowsets, SP's,
> input/output parameters - why cant they sort it out so that if there are,
> say, 6 different methods, say, of retrieving data - we all know the
> overhead of using each method - nothing is left undocumented - we all know
> under what circumstances SET FMTONLY ON, NO_BROWSETABLE (which I have seen
> before - 4 years ago) are issued and why.
>
> Does anyone really believe with ODBC, DAO, RDO, ADO, ADO.NET - each
> generation has been an improvement?
> They are all interfaces on the same set of database technology - which
> does not change.
>
> Stephen Howe
>
Navigation:
[Reply to this message]
|