In ADO you don't have the CurrentDb function to return a database against which to run the .Execute method. Instead you use the .Execute method of a Connection object that you create and set pointing to the appropriate data provider and path to database. The online help is pretty clear.
Just for the record, Access still uses DAO internally for bound recordsets and list and combo box row sources. Things like Docmd and domain aggregate functions do also. Why? Because the ADO and ADOX are more generic in order to work against a broader range of data providers. All the extra weight and overhead of being able to work against various data providers adds a layer of translation code between Access and the backend data whereas DAO uses Jet natively which is the direct mdb data provider. ADO is like having a ballerina wear a pair of work boots over her slippers. She can go to a construction site with the boots, but her dancing on the stage suffers. If she's going to dance on a stage, she does better without the extra layer of indirection but the boots allow her to go to job sites where she may be able to do some work, but she's somewhat out of her element in those environments.
ADO adds some versatility because you can hit Oracle or SQL Server backends and these can provide data more efficiently, but Access is not always the best front end for industrial strength disconnected transaction based data applications. If you want to upgrade to those kinds of backends, you would be well advised to work with ADO. However, your typical Mom & Pop to 20 local user 50 Megabyte databases (or fewer user/less size) are going to have to give up some performance to use ADO.
Edmonton AB Canada