ADO is a three-letter abbreviation for "ActiveX Data Objects". It is a Microsoft product. I agree that the repulsive pseudo-word "ActiveX" has earned its creator a well-deserved eternity in the lake of fire, but let's move on, shall we?
Thank you.
ADO supersedes the cleverly-named DAO ("Data Access Objects"). What they both are is a COM-wise (COM == "Component Object Model") interface1 for ODBC ("Open Database Connectivity"), yet another Microsoft thing. I think they sometimes call ODBC a "standard", but it's hard to hear what they're saying over all the giggling. What ODBC is, is a generalized interface for RDBMSs2. All of these little groups of capital letters are supposed to be part of something called "MDAC", or "Microsoft Data Access Components", which also includes "OLE DB"3 and "Remove Data Service".
Now that I've made everybody glad they don't have to deal with this stuff (or reminded them of how sorry they are that they do), what the hell is it, really?
The deal is this: Oracle, MS SQL Server, BDE4, and most other DBMSs implemented for Windows all provide ODBC "drivers". You can think of a "driver" as a sort of "adapter": Do you have one of those little cylindrical plugs that came with a pair of headphones, the ones with a 1/8" jack on one end and a 1/4" plug on the other? That's an adapter. Radio Shack makes a few dozen different variations on that theme, which accept all different kinds of plugs in the back -- but they all plug into that same headphone jack on your stereo, so you can plug anything into it that pleases you. ODBC works on a similar principle: Each vendor provides something with a "back" that talks in a private and peculiar way to his own database system, and a "front" which talks to ODBC in a way which is consistent. Therefore, a program can talk to Oracle and BDE in exactly the same way, even though they're really quite different inside. Of course, this turns out to be something of a "least common denominator" situation: It doesn't support 100% of what every database can actually do. It just supports all of the "normal" features that they all have in common.
That's not a bad thing at all, when you think about it. The problem is that ODBC is what we call a "low level" C API5: There's a lot of detail. You've got to write a lot of code and keep track of a lot of details in order to make anything happen. ADO hides all the mind-numbing fiddly stuff and lets you order ODBC around in relatively simple, broad terms. It's got a bunch of different "objects" representing a connection to a database, a "recordset", fields belonging to records, and so on and so forth. You can give it SQL queries and generally do what you need to with the database. It's handy, and it's far, far simpler to use than a C API for a database engine. Not least, you don't have to write in C when you're just doing throwaway code: You can write it in a very high level language that's well-suited to writing quickies.
I don't think you'd use it if you were doing anything really serious, though. There's probably a lot of overhead, and with these things you always lose fine control.
ADO is much used for doing web pages with ASP6. As with PHP and JSP, you can throw something together relatively quickly which will spit out a web page containing information from a database. You can also do the same with a script running outside a web server in the so-called Windows Scripting Host, so you can do a query and generate a report as text to stdout like God intended. Of course you don't have printf, but it's relatively trivial to whack up a printf for an interpreted language. I've got one around here somewhere that I wrote. One of these days I'll quick stuff it in a COM object when nobody's looking. And then you know what I'll have?
Far too much time on my hands.
1 "Interface" in the general sense, not the COMmunistic IUnknown sense.
2 "Relational database management systems" or something like that. BTW, AFAIK there's a reasonably lucid writeup in DBMS, IIRC.
3 Object Linking and Embedding Databases. OLE is what ActiveX used to be called. I think ActiveX is called COM now, or DCOM, or COM+, or some damn arbitrary thing. Nobody really cares. The names are all just marketing gibberish. They'll change again by this time next year.
4 Borland Database Engine -- you didn't think I was running out of these stupid things, did you? Fat chance! And I'm not even a database programmer!
5 Application Programming Interface. Very loosely speaking, an API is the "outside" of a code library. It's what a computer program talks to when it wants the library code to help it out by doing something boring, unpleasant, or pointless. With any luck, it'll be all three.
6 Active Server Pages, yet another miserable Microsoft product.