Activex Data Object

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.