ActivexDataObject (ADO) is a MicroSoft technology. It provides an ObjectModel to ease the use of ComponentObjectModel based OleDb data resource interface.

There is an extension to this library called ADOX. It stands for ActiveX Data Objects Extensions for Data Definition Language and Security.

With the introduction of MicrosoftDotNet, there is an AdoDotNet which has slightly different capabilities to the original ActivexDataObject.

It is said the original ADO will still be recommended to be used by DotNet applications requiring features not available in AdoDotNet.


----
Introductory resources
	* Mastering ADO from Windows and .NET mag http://www.winnetmag.com/Articles/Print.cfm?ArticleID=8028 
	* Introduction to disconnected recordsets http://www.devx.com/getHelpOn/10MinuteSolution/20407 

----
General references 
	* ADO History http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdmscwhatsnewinado.asp
	* ADOX fundamentals http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/admscadoxfundamentals.asp
	* ADOX Command Strategies http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvbdev00/html/vb00j1.asp


----
Any body able to share experience where use of ActivexDataObject in a DotNet application makes sense?

''See April2004 MS article at http://msdn.microsoft.com/data/default.aspx?pull=/library/en-us/dnsql2k/html/sqlserverprog.asp  It said server cursors and schema manipulation are reasons for continued use of ADO. Otherwise much of the functionality is built into DotNet and its use meant unneeded overhead.''

''Question is whether anyone really think transporting data across the network is a better option than the use of server based cursors for real-life applications''

----
'''ADO and XML'''

ADO does Xml, to some extent. See http://www.devx.com/getHelpOn/10MinuteSolution/20331/1954?pf=true for an example where such need exists and how to do it.