SoloCodigo

Bueno mira, por ejemplo ya sabes que Public se utiliza para que una variable esté disponible para todos los modulos, es decir, es publica y eso hace que dicha variable esté disponible para todos los procedimientos de la aplicación.

Lo que muestras ahí es DAO porque en ADO se usa Connection en vez de Database porque en ADO todas las bases de datos se acceden mediante una conexión, sea locales o remotas, es por eso que no se usa Database en ADO.  Los obtejos Recordset se crean directamente en la declaración de la variable mediante la palabra clave New

En DAO los Recordset se crean en el precioso momento de especificar de dónde provendrán sus datos.

Esto es un ejemplo de unas prácticas de hace ya un cierto tiempo, ejemplo:

DAO:
Dim BD as Database
Dim Rs as Recordset

Set BD = OpenDatabase(Ruta de la BD)
Set RS = BD.OpenRecordset(Sentencia SQL)

ADO:
Dim BD New Connection
Dim Rs as New Recordset

BD.Open "Provider=SQLOLEBD;" & _
"User ID=sa;" "Pwd=;" & _
"Initial Catalog=VideoClub;" & _
"Data Source=(local)"

Rs.Open SQL

El ejemplo de ADO se conecta a la BD por medio de OLE BD en donde se establece el nombre del proveedor OLE BD, el provider es SQLLEDB, el nombre del usuario y la contraseña, esta es una conexión local.

Tienes un ejemplo de conexión con ADODC en la nota anterior a esta, de otro usuario.

Te recomiendo que experimentes prácticando tanto con ADODC (ADO Data Control) y con ADODB (ADO Data Base)

Dim Rs as ADOBD.Recordset
Set Rs = New ADOBD.Recordset


Saludos.

Pues perdon yo pensé que era más especificamente hacia código.

Una pregunta, lo que quieres saber es la teoria entre DAO vs ADO.

Cuando se trata de Base de Datos Access:
Es recomendable utilizar DAO en vez de ADO, esto principalmente cuando se trabaja con (.mdb) Bases de datos Access y es porque DAO es algo más rápido para Bases de Datos Access a diferencia de ADO y es precisamente porque DAO interactua directamente con el Motor Jet de Access mientras que ADO lo hace a traves de "un intermediario" el cual es la interfase ODBC u OLE DB, si haces la prueba y tomas el tiempo verás que una consulta a una BD algo considerablemente llena, arrojará el resultado de datos un poco más rápido con DAO que con ADO, suponiendo que haces ese evaluativo en paralelo con DAO y ADO.  Tomando en cuenta que el motor jet de Acces es bastante voluminoso.

Cuando no son Bases de Datos Access:
En este caso, ADO resulta ser algo más conveniente, (si no es Access) ya que ADO posee más funcionabilidad que DAO, ADO es más simple porque define una menor cantidad de clases y está diseñado especialmente para simplificar el acceso a bases de datos remotas y cliente/servidor.
Para BD remotas o sistemas distribuidos, ADO es la opción más indicada porque ADO es soportado plenamente por Internet Information Server el cual es el servicio Web de Microsoft e igual las páginas ASP (Active Server Pages).

También antes cuando se trataba de Bases de datos  Access superior al Access97, obviamente ADO no servía porque sólo entendía hasta el motor jet 3.50 o 3.6 y Access2000 incorpora el motor jet 4.0.  Pero ahora se puede bajar de la web de Microsoft el MDAC 2.7, así que eso indica de que DAO no se queda atrás y se actualiza.

Hasta donde sé, DAO incorpora un mecanismo conocido como ODBCDirect mediante el cual DAO accede directamente a las fuentes de datos de ODBC.

ODBC: ODBC es la interfase estándar mediante la cual una aplicación puede acceder a cualquier BD sin preocuparse por los mecanismos de acceso particulares que esa BD posea.

PD: Prueba la velocidad de ADO y DAO en una BD Access y verás que ADO es 10 veces más lento que DAO, pero para sistemas remotos, usa ADO.