Rendimiento de Access contra backend Access en servidor de archivos remoto. Aclaración.

Antes de continuar con nuestra serie de artículos sobre Rendimiento de Access como Backend de servidor que están incluidos en la serie de artículos sobre Rendimiento de Access contra bases de datos de servidor me gustaría hacer una aclaración sobre los tipos de consultas utilizados en todas las pruebas.

Recomiendo la lectura de los artículos antes de leer este:

• Rendimiento de Access contra backend Access en servidor de archivos remoto. Primera parte.
• Rendimiento de Access contra backend Access en servidor de archivos remoto. Segunda parte.
• Rendimiento de Access contra backend Access en servidor de archivos remoto. Tercera parte.

Podréis observar que en todos los artículos existen varios tipos de consultas en los que utilizo DAO y ADO. Como no he explicado mucho la manera de utilizar estos 2 tipos de acceso a datos en cada consulta, me gustaría aclararlo ya que probablemente cuando empecemos con los SGBD de servidor (Oracle, SQL-Server, MySql, Microsoft Azure, etc.) será un factor clave para el rendimiento.

Distintas consultas con método de acceso a datos DAO

Como sabéis los que seguís el blog, considero que DAO es el método más sencillo y a la vez más efectivo para utilizar con Access. Hubo una época en la que parecía que Microsoft iba a dar prioridad al nuevo (en aquella época) ADO, pero a partir de Office 2007 el método de acceso a datos por defecto vuelve a ser DAO.

No voy a entrar en si es mejor o peor que ADO utilizando orígenes de datos conectados mediante ODBC, sobre todo porque espero realizar las pruebas contra Microsoft Azure y SQL-Server en cuanto pueda (ahí veremos qué funciona mejor y en qué casos). Si queréis algo más de información (poca) podéis leer este artículo sobre Mi opinión sobre DAO y ADO.

Con DAO quería probar 3 tipos de consultas:

• Abriendo tablas vinculadas
• Abriendo directamente el origen de datos
• Intentando emular Pass Through

Como hemos visto, la emulación Pass Through (ver Explicación de Pass Through con DAO en la parte central del artículo) no funciona muy bien, los tiempos aunque mejores que con el generador de consultas de Access, son bastante peores que utilizando DAO para abrir las tablas.

Pero la parte interesante de este artículo está en las otras 2 maneras de funcionar con DAO. Se pueden utilizar directamente las tablas vinculadas o conectar estableciendo el origen de datos en la base de datos de servidor. Voy a mostrar un ejemplo de cada una abriendo un recordset:

DAO con tablas vinculadas

Set dbs = CurrentDb
Set rst = dbs.OpenRecordset("Sentencia SQL contra las tablas vinculadas")

DAO abriendo directamente origen de datos

BaseDatos = "\\ruta_servidor\PRUEBAS.accdb"
pass = ""
Set ws = DBEngine.Workspaces(0)
Set dbs = ws.OpenDatabase(BaseDatos, False, False, "MS Access;PWD=" & pass & "")
Set rst = dbs.OpenRecordset("Sentencia SQL contra las tablas vinculadas")

Esto que puede parecer que no tiene mucho sentido plantearlo cuando hablamos de un BackEnd Access, tendrá una gran importancia cuando hagamos las pruebas contra SBGD de servidor. Veremos entonces la manera que tiene Access de gestionar las tablas vinculadas, como podemos realizar las consultas en servidor, formas de hacer Pass Through, etc.

¿Y en este caso? ¿Cuál de las 2 maneras es mejor?

Pues a lo mejor os sorprende, o a lo mejor no, pero Access trata de la misma forma las 2 maneras de conexión (por lo menos los tiempos son casi clavados). Es lógico ya que el motor de base de datos es el mismo. Así que cuando hablo de DAO en los artículos, da igual si utilizo un tipo u otro, los tiempos son iguales. Por no repetir, he utilizado la segunda forma en todos los artículos.

Distintas consultas con método de acceso a datos ADO

Se supone que con ADO, todo es Pass Through. Es decir, se abre el origen de datos y la consulta se ejecuta en el servidor. De hecho, no he encontrado la manera de utilizar directamente las tablas vinculadas, tiene que abrir la base de datos que hace de backend. Así que cuando hablo de ADO en los artículos, hablo de algo como esto:

strCon = "Provider=Microsoft.ACE.OLEDB.12.0;" & _
    "Data Source=\\ruta_servidor\PRUEBAS.mdb;" & _
    "User Id=admin;Password="
  
    conn.Open (strCon)
    
    qry = "Sentencia sql"
    rst.Open qry, conn, adOpenKeyset

Los tiempos son muy parecidos a los que obtenemos con DAO, pero siempre algo peores. Creo que las diferencias pueden estar a la hora de actualizar/añadir datos (lo veremos pronto) y sobre todo cuando de verdad se nos permita realizar Pass Through (cuando utilicemos SGBD de servidor.

Espero que os haya aclarado las posibles dudas.

The following two tabs change content below.

• Bio
• Latest Posts

Arkaitz Arteaga

Administrador at Programador de Palo

Llevo más de 10 años programando, sobre todo en Visual Basic y con bases de datos Access. Para mí, VBA y Access siguen siendo herramientas muy potentes. He desarrollado varios proyectos con PHP y MySql. Si sumo las webs que he tenido, probablemente pasaría de 100. Ahora prefiero dedicar todo mi esfuerzo a este blog (aunque sigo manteniendo unas cuantas...). Trabajo en la administración pública (si, soy funcionario), pero he trabajado en pequeñas empresas e incluso en una "grande" de las telecomunicaciones. Ultimamente estoy bastante metido en abrirme nuevos horizontes con C# y .NET. Renovarse o morir!

Latest posts by Arkaitz Arteaga (see all)

• Access: Encriptar contraseñas con SHA-256 utilizando biblioteca de clases .NET con C# - 4 mayo, 2014
• Rendimiento de Access contra backend Access en servidor de archivos remoto. Cuarta parte. - 27 abril, 2014
• Rendimiento de Access contra backend Access en servidor de archivos remoto. Aclaración. - 21 abril, 2014
• Utilizar biblioteca de clases .NET en Access. Tercera aproximación a la Interoperabilidad COM - 14 abril, 2014
• Vincular tablas en Access con Visual Basic - 11 abril, 2014