Antes de proseguir, voy a pedir a los que no han leído los correos anteriores, que vean las páginas

Acceso a Datos 03: Bases, Formatos y Motores

datos03 que contiene las diferencias entre ADO y DAO, y

Acceso a Datos 06: Acceso a campos y ABC DAO Simple

datos06.htm que trae ejemplos de cómo accesamos a los datos en DAO.

Lo que sigue va a suponer que ya lo leyeron. A grandes rasgos DAO era una forma de accesar datos que diseñó Microsoft, que evolucionó después en ADO.

Tipo de Acceso: [color=#FFFFCC]DAO

[color=#FFFFCC]Ventajas:

1. Sistema de búsqueda muy robusto
2. Permite modificar tablas dinámicamente

[color=#FFFFCC]Desventajas:

1. Lentitud relativa

Tipo de Acceso: [color=#FFFFCC]ADO

[color=#FFFFCC]Ventajas:

1. Rapidez
2. Muy portable

[color=#FFFFCC]Desventajas:

1. Deben seleccionarse los drivers con cuidado
2. No permite modificar dinámicamente tablas SQL SERVER (con ADOX si es posible)
3. Sistema de búsqueda No SQL menos poderoso.
4. Mucha funcionalidad extra que no se necesita ( objetos stream y record )

Sin embargo, aunque ADO y DAO son muy parecidos, surge mucho el problema de elegir cual es mejor. La respuesta es simple. ADO es mejor, y si necesitamos por algo en especial las ventajas de DAO, podemos usar los dos en un solo sistema, en la actualidad lo normal es usar consultas SQL desde código Visual Basic para suplir las desventajas de ADO en cuanto a motor.

Técnicamente es posible hacer un programa DAO estructurado de tal manera que podamos hacerlo ADO sin esfuerzo. Lo veremos ya que programaremos en DAO, y finalmente haremos ajustes que realicen el cambio. Esto es característico de los buenos programadores. No Necesito decir nombres, pero todos conocemos a programadores que se tardan semanas, a veces meses y años, en cambiar sus sistemas en metodologías de acceso, simplemente porque no están bien estructurados. En otro correo hablábamos de los programas ABC, es decir, los procesos de altas, bajas y cambios de todos los módulos de un proceso determinado. En el correo 06, vimos que era posible accesar a los datos a través de un recordset, o conjunto de resultados, que se transformaban, ordenaban y modificaban en base a una sola cadena SQL. Aunque más adelante veremos con mas detalle SQL, vamos a ver muy rápidamente lo que es la sintaxis de la apertura de recordsets.

1. Debe usarse en DAO un openrecordset.
2. Toda consulta de registros empieza con un “select”, seguido por el nombre del campo o campos a consultar, terminando con una orden from que va a decir de donde es la tabla a usar. El orden de los campos en la declaración, será el orden en los resultados. Puede sustiuirse el nombre de los campos por un asterisco, pero esto llama todos los campos, no solo los solicitados.

1. Select NOMBRE,DIRECCION from ALUMNOS
2. Select DIRECCION,EDAD from ALUMNOS

1. Podemos filtrar con la cláusula where

1. Select NOMBRE,TELEFONO from ALUMNOS where TELEFONO=’5678-1234’
2. Select TELEFONO,EDAD from ALUMNOS where EDAD > 18

1. Y podemos ordenar en base a una cláusula order by.

1. Select NOMBRE,APELLIDO from ALUMNOS order by APELLIDO
2. Select * from ALUMNOS where EDAD <18 order by EDAD

Lo interesante es que el secreto de SQL es mantener las ordenes sencillas, no complicadas, y sobre todo evitar usar el asterisco en lugar del nombre de los campos. Esto se debe a que en una tabla con muchos campos, es más eficiente cargar solo los necesarios y usar asterisco los carga todos.

Una vez que sabemos que consultar, tenemos que saber como revisar si hay o no resultados a nuestra pregunta. ADO y DAO nos ofrecen dos métodos, uno usando la palabra clave nomatch que no entra en el espíritu de SQL, y la orden según SQL.

Vamos a suponer que pedimos los alumnos mayores a 18 años en una escuela primaria. Casi seguramente no hay resultados, no?

Un ejemplo de código sería:

[code]Dim db as DAO.database
Dim rs as DAO.Recordset
Set db= OpenDatabase(“alumnos.mdb”) ‘ esto abre la base de datos en Access
Set RS= db.openrecordset(“Select * from ALUMNOS where EDAD <18 order by EDAD”) ‘ abre
With rs