Conexión a bases de datos Microsoft Access mediante ADO + ODBC

Artículos y recursos relacionados

• KB-LJW-DB-101 : Impacto de los tipos de cursores ADO en un controlador ODBC en ASP

Drivers Microsoft Access instalados en nuestros servidores Classic ASP

Los Drivers ODBC y Provider OLEDB nativos que le permiten conectarse a las bases de datos Microsoft Access están instalados en nuestros alojamientos compartidos Classic ASP, y están disponibles en 32 bits y 64 bits:

•  {Microsoft.Jet.OLEDB.4.0}
•  {Microsoft.ACE.OLEDB.12.0}
•  {Microsoft Access Driver (*.mdb)}
•  {Microsoft Access Driver (*.mdb, *.accdb)}

Qué son las bases Microsoft Access

Las bases Microsoft Access son bases de datos relacionales almacenadas en un archivo .mdb o .accdb. Se basan en el motor histórico Jet Database Engine (Jet.OLEDB), y ahora en Access Database Engine (ACE.OLEDB 12/14/16).

Frecuentemente utilizadas en desarrollo Classic ASP, las bases Access son ante todo una fuente de datos relacional simple porque son accesibles sin servidor de base de datos dedicado. Puede consultarlas mediante el lenguaje SQL, con a veces algunas adaptaciones y especificidades del dialecto SQL para Access .

En el plano técnico, Access organiza los datos en tablas, relaciones, índices y consultas, de manera comparable a otros SGBD. El acceso a sus bases Access se efectúa en Classic ASP típicamente vía ADO (ActiveX Data Objects), utilizando ya sea un proveedor OLE DB (por ejemplo Microsoft.Jet.OLEDB.4.0 o Microsoft.ACE.OLEDB.12.0), ya sea el Driver ODBC proporcionado por Microsoft Microsoft Access Driver (.mdb, .accdb).

Las bases Access son adecuadas para sitios con tráfico y volumen de datos intermedios, debido a que no existe una separación estricta entre motor, almacenamiento y acceso concurrente. Todos estos roles están encapsulados en un único archivo: conexiones, objetos Recordset, consultas SQL, transacciones.

Cómo gestionar y administrar las bases Access

Debido a que las bases de datos Microsoft Access se proporcionan en forma de archivo independiente, su uso es sencillo. Basta con colocar un archivo .mdb o .accdb en un directorio de su sitio web, y su código ASP posee los derechos para acceder a él. Según la fórmula de alojamiento dedicado o compartido de la que disponga, puede utilizar un número ilimitado de bases .mdb o .accdb.

La gestión de las bases Access se efectúa en la mayoría de los casos por transferencia FTP, y mediante gestión directa desde páginas codificadas en Classic ASP. Las páginas destinadas a la parte pública de su sitio web tienen por lo general la finalidad de leer los datos (con algunos casos de escritura), mientras que sus páginas de tipo "Administrador/Backoffice/Manager/Intranet" le permiten operaciones de escritura y actualización de sus datos como explotador del sitio.

La gestión remota de sus bases de datos desde la aplicación Microsoft Access instalada en su ordenador es técnicamente posible, pero en general solo es fiable desde una red local. Las condiciones de una base Access situada en un servidor web remoto no están adaptadas a esta técnica, o bien con riesgos importantes de corrupción de datos, o períodos de bloqueo que vuelven su base inaccesible para los accesos concurrentes del lado del sitio web público, o bloqueos fantasma y tiempos de respuesta imprevisibles.

Estas limitaciones son inherentes al hecho de que Microsoft Access es un motor de base de datos basado en un archivo único, y no un servidor de bases de datos. El acceso a las bases solo es posible, por tanto, con una concurrencia de conexiones muy baja, y siempre al precio de un bloqueo de la base. Un acceso remoto no es por tanto una elección fiable desde un punto de vista operativo.

Cómo acceder a las bases Access desde ASP Classic

La conexión a sus bases de datos Microsoft Access desde su sitio Classic ASP se efectúa a través de un Provider OLEDB nativo, o bien de un Driver ODBC proporcionado para ello por Microsoft. Las diferencias entre OLE DB y ODBC se presentan en esta sección.

El método de conexión que debe privilegiarse depende principalmente del bitness (32 bits o 64 bits) de su Application Pool IIS. La regla principal de elección es la siguiente:

•  {Microsoft.Jet.OLEDB.4.0}:
  Antiguo provider OLEDB adaptado a las conexiones de 32 bits
•  {Microsoft.ACE.OLEDB.12.0}:
  Provider OLEDB actual adaptado a las conexiones de 64 bits
•  {Microsoft Access Driver (*.mdb)}:
  Solución de reserva si OLEDB no conviene, disponible en 32 bits
•  {Microsoft Access Driver (*.mdb, *.accdb)}:
  Solución de reserva si OLEDB no conviene, disponible en 64 bits

La tabla siguiente le presenta los diferentes métodos de acceso a sus bases Access:

Conexión directa sin DSN mediante un Driver ODBC o Provider OLE DB

Cuando establece una conexión a su base Microsoft Access mediante un Driver ODBC desde su código ASP, establece una conexión denominada "DSN-Less". En este caso no necesita especificar Provider=MSDASQL (Microsoft OLE DB provider for ODBC) en su cadena de conexión: este provider OLE DB predeterminado para los Drivers ODBC es utilizado implícitamente por ADO.

Una excepción que debe tenerse en cuenta: probablemente deberá añadir Provider=MSDASQL; DSN=MiDSN; a su cadena de conexión si establece su conexión mediante un DSN.

Microsoft.Jet.OLEDB.4.0

Microsoft.Jet.OLEDB.4.0 es el proveedor OLE DB que permite a ADO acceder al Jet Database Engine , el motor histórico de Microsoft Access. Funciona exclusivamente con archivos .mdb y solo en 32 bits. Durante mucho tiempo fue privilegiado en Classic ASP para los sitios ejecutados en un Pool de Aplicación IIS configurado en 32 bits. En un Pool de 64 bits, debe ser sustituido por Microsoft.ACE.OLEDB.12.0.

Jet sigue instalado en la mayoría de los servidores de alojamiento web para asegurar la compatibilidad de los numerosísimos sitios web ASP ejecutados en Pools de Aplicación IIS en 32 bits. Su funcionamiento es estable en aplicaciones históricas. Tenga en cuenta, sin embargo, que ya no se mantiene y que impone restricciones notables en términos de concurrencia y fiabilidad. La migración a 64 bits debe privilegiarse.

El siguiente ejemplo le muestra cómo establecer una conexión a una base Access mediante el Provider JET OLE DB en 32 bits:

<%
'Establecer la conexión a la base de datos Access mediante el proveedor JET OLE DB 4
'Disponible para los Application Pool en 32 bits
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open "Provider=Microsoft.Jet.OLEDB.4.0; DATA SOURCE=base.mdb;"
%>

Si desea efectuar operaciones que requieren un acceso exclusivo a su base Access, añada el parámetro Mode=Share Exclusive; a su cadena de conexión. Asegúrese de no bloquear de manera prolongada su base con este procedimiento, para que las páginas públicas de su sitio puedan conectarse a la base.

Microsoft.ACE.OLEDB.12.0

Microsoft.ACE.OLEDB.12.0 es el proveedor OLE DB que expone el Access Database Engine  (ACE), sucesor oficial de Jet. Es compatible con los formatos .accdb y .mdb y funciona en 64 bits (y/o en 32 bits si está instalado). Está destinado a reemplazar a Jet en los accesos programáticos a Access mediante ADO desde sus páginas Classic ASP.

ACE no es un simple cambio de nombre de Jet: es un motor diferente y más reciente, con más tipos de datos y una mejor compatibilidad Unicode. En cambio, no transforma Access en una base servidor: persisten las mismas limitaciones estructurales.

El siguiente ejemplo le muestra cómo establecer una conexión a una base Access mediante el Provider ACE OLE DB en 64 bits:

<%
'Establecer la conexión a la base de datos Access mediante el proveedor ACE OLE DB 12 (o 14, o 16)
'Disponible para los Application Pool en 64 bits
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open "Provider=Microsoft.ACE.OLEDB.12.0; DATA SOURCE=base.mdb;"
%>

Si su base está protegida por una contraseña, especifíquela en su cadena de conexión con el parámetro Jet OLEDB:Database Password=yourPassword;. Este método requiere en algunos casos que utilice una contraseña que no contenga caracteres especiales y cuya longitud no exceda los 14 caracteres. Por último, algunas bases cifradas con Access 2010 - 2013 pueden no funcionar; en ese caso debe elegir el cifrado de tipo Access 2007.

Microsoft Access Driver (*.mdb, *.accdb)

El Microsoft Access Driver (.mdb, .accdb) es un driver ODBC históricamente diseñado para permitir el acceso a las bases Access mediante el protocolo ODBC. Sin embargo, cuando se utiliza con ADO, se apilan las siguientes capas: ADO > ODBC > Jet/ACE. Utilizar ODBC en este contexto es técnicamente inferior en el sentido de que añade una capa de abstracción innecesaria que degrada ligeramente el rendimiento. Desde su código Classic ASP, debe privilegiarse un Provider OLE DB (Jet/ACE), ya que es más directo y está mejor integrado.

El siguiente ejemplo le muestra cómo establecer una conexión a una base Access mediante el Driver ODBC en 32 bits:

<%
'Establecer la conexión a la base de datos Access mediante el controlador ODBC
'Disponible para los Application Pool en 32 bits
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open "Driver={Microsoft Access Driver (*.mdb)}; Dbq=base.mdb; Uid=Admin; Pwd=;"
%>

El siguiente ejemplo le muestra cómo establecer una conexión a una base Access mediante el Driver ODBC en 64 bits:

<%
'Establecer la conexión a la base de datos Access mediante el controlador ODBC
'Disponible para los Application Pool en 64 bits
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open "Driver={Microsoft Access Driver (*.mdb, *.accdb)}; Dbq=base.accdb; Uid=Admin; Pwd=;"
%>

Si desea efectuar operaciones que requieren un acceso exclusivo a su base Access, añada el parámetro Exclusive=1; a su cadena de conexión. Asegúrese de no bloquear de manera prolongada su base con este procedimiento, para que las páginas públicas de su sitio puedan conectarse a la base.

Conexión mediante un DSN

La conexión a una base Microsoft Access mediante DSN es posible haciendo uso del Driver ODBC, pero no del Provider OLE DB nativo.

Si dispone de un alojamiento compartido proporcionado por El Web Justo, puede conectarse a una base de datos Access mediante un DSN procediendo de la siguiente manera:

1. Conéctese a Plesk
2. Vaya a la pestaña « Dashboard » y luego haga clic en « ODBC Data Sources »
3. Haga clic en el botón « Add ODBC DSN »
4. Introduzca la información de autenticación de su base de datos Access, así como los parámetros correspondientes a esta conexión ODBC.
5. En su código ASP, ahora puede conectarse a este DSN ODBC utilizando uno de los métodos siguientes:
   ASP CLASSIC

   <%
   'Establecer la conexión a la base de datos Access mediante un DSN
   'Disponible para los Application Pool en 32 bits y 64 bits
   Dim objConn
   Set objConn = Server.CreateObject("ADODB.Connection")
   objConn.CursorLocation = 3 'adUseClient (cf. "adovbs.inc")
   
   'Método 1
   objConn.ConnectionString = "DSN=DSNname;Uid=Username;Pwd=Password"
   objConn.Open
   
   ''Método 2 (alternativo)
   'objConn.Open "DSNname", "Username", "Password"
   %>

   
   

En nuestros alojamientos compartidos, puede en cualquier momento ajustar el bitness del Application Pool en Plesk en la pestaña « Hosting & DNS > Dedicated IIS Application Pool for Website » en la opción « Enable 32-bit applications ».

Consejos y casos particulares con Microsoft Access

Microsoft Access es un sistema sencillo que ofrece una implementación rápida y poco costosa, lo que lo convierte en una elección natural y adecuada en muchos casos para sitios Classic ASP. Sin embargo, debido a que se trata de un sistema de bases de datos por archivo sin servidor, ciertas limitaciones estructurales importantes para un uso en su sitio web deben tenerse en cuenta durante su utilización.

La gestión de la concurrencia es rudimentaria, el rendimiento puede caer durante accesos simultáneos, y el riesgo de corrupción del archivo aumenta bajo cargas fuertes o numerosas consultas. El dialecto SQL utilizado por Jet/ACE difiere del estándar SQL estricto, lo que puede complicar la redacción de consultas avanzadas y disminuir la portabilidad de la base.

Si encuentra alguna dificultad, no dude en contactarnos.

Corrupción de base & Backups

Los riesgos de corrupción de datos de una base Access son reales. Las bases Access se basan en un archivo único (.mdb / .accdb) al que accede directamente el motor Jet o ACE. Esta arquitectura expone la base a corrupciones en caso de escritura interrumpida, como por ejemplo una parada brusca del servidor IIS, un fallo de la aplicación, un corte de red, o un bloqueo concurrente mal gestionado, o cuando se explotan en sitios que reciben un tráfico a veces considerable, o bien también un número muy elevado de consultas en períodos cortos. Cuanto más frecuentes y simultáneas son las escrituras, más aumenta el riesgo. La corrupción de su base puede ser parcial (algunas tablas o índices ilegibles), o total, dejando la base inutilizable.

Incluso una base "bien diseñada" puede corromperse: ciertos factores deben alertarle de problemas de corrupción inminentes:

•  Múltiples accesos concurrentes en escritura
•  Bases voluminosas o cercanas a su límite de 2 GB
•  Ausencia de compactación regular
•  Código ASP que no cierra correctamente las conexiones y recordsets

Las copias de seguridad regulares son indispensables. Se trata, en efecto, del único medio fiable de recuperación de los datos tras una corrupción severa de su base. Conserve varias copias de seguridad históricas durante un período de retención (por ejemplo 1 semana o 1 mes) suficientemente largo para permitirle identificar el problema de corrupción y restaurar el conjunto de datos que le conviene.

Las herramientas de reparación integradas en la aplicación Microsoft Access a veces pueden restaurar una base, pero sin ninguna garantía de integridad de los datos. Los backups que realiza no sirven únicamente para las corrupciones de datos, sino también para los errores humanos que pueden producirse cuando codifica o interviene en su base (ej. eliminación accidental, actualización incorrecta). Recuerde que "hacer copias de seguridad de vez en cuando" o únicamente antes de una operación arriesgada es insuficiente.

Siga las siguientes buenas prácticas de copia de seguridad:

•  Haga copias de seguridad de manera automatizada y regular (diaria como mínimo)
•  Haga copias de seguridad fuera de línea (cuando la base esté cerrada + con acceso exclusivo)
•  Conserve varias versiones (rotación)
•  Pruebe periódicamente la viabilidad de sus bases guardadas

Cursor predeterminado

ADO nunca deja el control al cursor predeterminado del Driver ODBC, y especifica como mínimo 0=adOpenForwardOnly. Esto significa concretamente que incluso si no especifica la propiedad rs.CursorType, el cursor predeterminado del Driver ODBC Microsoft Access no se aplica.

Consulte nuestro artículo KB-LJW-DB-101 sobre este tema.

Tamaño máximo de 2 GB

Una base Microsoft Access posee teóricamente un tamaño máximo de 2 GB por archivo (.mdb o .accdb). Este límite incluye todos los datos, pero también los índices, los objetos del sistema, las tablas temporales y el espacio interno no utilizado.

En la práctica, una base Access se vuelve inestable mucho antes de 2 GB. El rendimiento se degrada fuertemente a partir de 1 ~ 1,2 GB, sobre todo en presencia de escrituras frecuentes. Por tanto, el límite operativo realista se sitúa más bien alrededor de ~1 GB. Operaciones como las consultas complejas, las actualizaciones masivas o la creación de índices requieren espacio temporal, lo que puede provocar errores incluso si el tamaño final de su base sigue siendo inferior a 2 GB.

Algunos puntos frecuentemente mal entendidos acerca de las bases Access:

•  Eliminar datos no reduce el tamaño del archivo sin compactación posterior.
•  Los campos de tipo OLE Object / Attachment consumen espacio muy rápidamente. Almacene más bien estos datos binarios en archivos en el disco.
•  Las tablas temporales y las consultas de ordenación pueden fallar por falta de espacio interno, sin que el disco esté lleno.
•  El motor Jet/ACE no reparte los datos en varios archivos. Solo dispone de un único archivo por base Access.

Este límite arquitectónico inherente a las bases Microsoft Access las vuelve rápidamente inadecuadas para bases voluminosas o de crecimiento continuo. Algunas de las estrategias más frecuentemente utilizadas para eludir este problema de tamaño son, por ejemplo:

•  Separar los datos en varias bases (particionamiento manual). Esto presenta rápidamente el inconveniente de tener que gestionar manualmente varios archivos de bases, lo que aumenta los riesgos de confusión.
•  Archivar regularmente los datos antiguos en otras bases de almacenamiento "frías"
•  Migrar hacia un verdadero servidor de base de datos (por ejemplo MariaDB o SQL Server) cuando el tamaño se vuelve estructuralmente crítico

Compactación y mantenimiento

Con el paso del tiempo, el tamaño de su base Access crece. En cada modificación de datos, se deja espacio vacío en la base y no se purga. La compactación de una base Microsoft Access es una operación de mantenimiento que reescribe completamente el archivo de base de datos (.mdb o .accdb). Consiste en suprimir el espacio dejado por los registros eliminados o modificados, y en reorganizar las páginas de datos y reconstruir ciertos índices.

La compactación no es una operación de emergencia opcional, sino una práctica que debe integrar en el ciclo de vida de su aplicación ASP. Tenga en cuenta, sin embargo, que la compactación no corregirá una mala arquitectura y no mejora la gestión de la concurrencia, ya que esta última es inherente al propio motor. Las razones que deben llevarle a compactar sistemáticamente su base de manera regular son las siguientes:

•  Reducción del tamaño del archivo
•  Mejora del rendimiento (consultas, índices)
•  Disminución del riesgo de corrupción
•  Restauración de la coherencia interna tras numerosas operaciones de escritura de tipo INSERT, UPDATE, DELETE

En la práctica, el motor Jet o ACE crea una nueva copia interna de la base, copia en ella únicamente los datos válidos y luego reemplaza el archivo original. Así se recupera el espacio en disco y se reoptimiza la estructura lógica. La operación de compactación abre la base en modo de acceso exclusivo, lo que hace que la base sea inaccesible durante esta operación. En bases de tamaño importante, esto puede bloquearla durante varios minutos, en particular si no se ha efectuado ninguna compactación recientemente. Por tanto, planifique siempre esta compactación fuera del período de uso.

Le recomendamos efectuar una compactación de su base Microsoft Access:

•  Para las aplicaciones poco modificadas: cada mes
•  Para las aplicaciones con escrituras frecuentes: cada semana
•  Para las aplicaciones muy activas: con mayor frecuencia y después de tratamientos pesados

Puede efectuar esta compactación de manera manual o automatizada mediante un script:

•  Mediante Microsoft Access: Desde el menú "Herramientas de base de datos > Compactar y reparar"
•  Mediante un script ASP o VBScript planificado: Utilice el motor Jet o ACE para compactar la base

Los siguientes códigos fuente (VBScript o ASP) le muestran cómo compactar su base Access de manera regular:

•  Si utiliza un Pool de Aplicaciones IIS 64 bits:
  
  ASP CLASSIC

  <%
  'Forzar un valor numérico a X dígitos, con prefijo de 0 (ej. 5 => 05)
  Function Num2Digits(data, numdigits)
     Num2Digits = Right(String(numdigits, "0") & CStr(data), 2)
  End Function 'Num2Digits
  
  'Mover/renombrar un archivo
  Sub MoveRenameFile(sSrc, sDest)
     Dim fso, f
     Set fso = Server.CreateObject("Scripting.FileSystemObject")
        fso.MoveFile sSrc, sDest
     Set fso = Nothing : fso = Empty
  End Sub 'MoveRenameFile
  
  'Definir la ruta hacia la base de datos Access de origen
  '(las rutas UNC son posibles pero no recomendadas con Access => riesgo de corrupción)
  Dim sFilePathFrom : sFilePathFrom = Server.MapPath("/data/base.accdb")
  
  Dim sDateTimeStamp : sDateTimeStamp = "_" & Year(Now()) & Num2Digits(Month(Now()),2) & Num2Digits(Day(Now()),2) & "_" & Num2Digits(Hour(Now()),2) & Num2Digits(Minute(Now()),2) & Num2Digits(Second(Now()),2)
  
  'Definir la ruta hacia la base de datos Access compactada
  '(las rutas UNC son posibles pero no recomendadas con Access => riesgo de corrupción)
  Dim sFilePathTo : sFilePathTo = Server.MapPath("/data/base_compactada" & sDateTimeStamp & ".accdb")
  
  'Definir las cadenas de conexión
  Dim sdbConnFrom, sdbConnTo
  sdbConnFrom = "Provider=Microsoft.ACE.OLEDB.12.0; Data Source=" & sFilePathFrom
  sdbConnTo   = "Provider=Microsoft.ACE.OLEDB.12.0; Data Source=" & sFilePathTo
  
  'Activar la gestión de errores
  Err.Clear
  On Error Resume Next
  
  'Compactar la base de datos Access desde "Data Access Objects" (64 bits)
  Dim oDAO
  Set oDAO = Server.CreateObject("DAO.DBEngine.120")
  oDAO.CompactDatabase sdbConnFrom, sdbConnTo
  
  if (Err.Number <> 0) then
     Response.Write "Error durante la compactación de """ & sFilePathFrom """ : " & Err.Number & " - " & Err.Description
  else
     'Renombrar la base compactada a Producción
     MoveRenameFile sFilePathTo, sFilePathFrom
  end if
  
  'Desactivar la gestión de errores
  Err.Clear
  On Error Goto 0
  %>

  
  
•  Si utiliza un Pool de Aplicaciones IIS 32 bits:
  
  ASP CLASSIC

  <%
  'Forzar un valor numérico a X dígitos, con prefijo de 0 (ej. 5 => 05)
  Function Num2Digits(data, numdigits)
     Num2Digits = Right(String(numdigits, "0") & CStr(data), 2)
  End Function 'Num2Digits
  
  'Mover/renombrar un archivo
  Sub MoveRenameFile(sSrc, sDest)
     Dim fso, f
     Set fso = Server.CreateObject("Scripting.FileSystemObject")
        fso.MoveFile sSrc, sDest
     Set fso = Nothing : fso = Empty
  End Sub 'MoveRenameFile
  
  'Definir la ruta hacia la base de datos Access de origen
  '(las rutas UNC son posibles pero no recomendadas con Access => riesgo de corrupción)
  Dim sFilePathFrom : sFilePathFrom = Server.MapPath("/data/base.mdb")
  
  Dim sDateTimeStamp : sDateTimeStamp = "_" & Year(Now()) & Num2Digits(Month(Now()),2) & Num2Digits(Day(Now()),2) & "_" & Num2Digits(Hour(Now()),2) & Num2Digits(Minute(Now()),2) & Num2Digits(Second(Now()),2)
  
  'Definir la ruta hacia la base de datos Access compactada
  '(las rutas UNC son posibles pero no recomendadas con Access => riesgo de corrupción)
  Dim sFilePathTo : sFilePathTo = Server.MapPath("/data/base_compactada" & sDateTimeStamp & ".mdb")
  
  'Definir las cadenas de conexión
  Dim sdbConnFrom, sdbConnTo
  sdbConnFrom = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & sFilePathFrom
  sdbConnTo   = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & sFilePathTo
  
  'Activar la gestión de errores
  Err.Clear
  On Error Resume Next
  
  'Compactar la base de datos Access desde "Jet and Replication Objects" (32-bits)
  Dim oJRO
  Set oJRO = Server.CreateObject("JRO.JetEngine")
  oJRO.CompactDatabase sdbConnFrom, sdbConnTo
  
  ''O (ALTERNATIVA)
  ''Compactar la base de datos Access desde "Data Access Objects" (32-bits)
  'Dim oDAO
  'Set oDAO = Server.CreateObject("DAO.DBEngine.36")
  'oDAO.CompactDatabase sdbConnFrom, sdbConnTo
  
  if (Err.Number <> 0) then
     Response.Write "Error durante la compactación de """ & sFilePathFrom """ : " & Err.Number & " - " & Err.Description
  else
     'Renombrar la base compactada a Producción
     MoveRenameFile sFilePathTo, sFilePathFrom
  end if
  
  'Desactivar la gestión de errores
  Err.Clear
  On Error Goto 0
  %>

  
  

  La versión del DAO.DBEngine que debe instanciarse depende de la versión del Provider ACE OLE DB instalado en el servidor. Nuestros alojamientos compartidos proporcionan la versión 12.

   Haga clic para ordenar por columna

  Motor	Provider OLE DB	DAO DBEngine
  Jet 4.0	Microsoft.Jet.OLEDB.4.0	DAO.DBEngine.36
  ACE 2007	Microsoft.ACE.OLEDB.12.0	DAO.DBEngine.120
  ACE 2010	Microsoft.ACE.OLEDB.14.0	DAO.DBEngine.140
  ACE 2016+	Microsoft.ACE.OLEDB.16.0	DAO.DBEngine.160

Si una conexión sigue abierta (archivo *.ldb o *.laccdb aún presente) la compactación fallará y se generará un error COM+. Por tanto, conviene implementar este código fuente preferentemente en un bucle que pruebe el acceso exclusivo con Set dbe = Server.CreateObject("DAO.DBEngine.36") : Set db = dbe.OpenDatabase("C:\data\base.mdb", True) y luego efectuar una pausa/sleep de 10 segundos antes del siguiente intento, o bien planificar su tarea en un momento del día con la menor actividad en su base. Otras estrategias avanzadas implican detener el Pool de Aplicaciones IIS desde VBScript, por ejemplo. Esto requiere, no obstante, derechos de acceso elevados en el servidor. Póngase en contacto con nosotros si necesita tales técnicas.

Gestión del bloqueo (archivos *.ldb y *.laccdb)

Los archivos .ldb y .laccdb son archivos de bloqueo utilizados por Microsoft Access para gestionar el acceso concurrente a la base de datos y son por ello inseparables de su funcionamiento interno. Cuando un usuario abre una base mediante el motor Jet/ACE, Microsoft Access crea automáticamente un archivo .ldb o .laccdb. El papel principal de este archivo es gestionar los bloqueos (locking), identificar a los usuarios conectados y evitar escrituras concurrentes incompatibles. Este archivo no contiene datos en sí, se crea en la misma carpeta que la base y desaparece cuando el último usuario cierra la base. La mayoría de los demás motores de base de datos gestionan estos accesos concurrentes en memoria RAM. El hecho de que Microsoft Access gestione esto en un archivo constituye de facto un cuello de botella: cada acceso a la base de datos ocasiona un acceso a disco, que resulta ser el tipo de memoria más lento.

El bloqueo en Access funciona por páginas de 2 KB o 4 KB según la versión, y no por línea, a diferencia de otros sistemas de bases de datos que funcionan sobre la base de un servidor, tales como MariaDB. Las consecuencias son que una sola modificación puede bloquear varios registros, pero también que el rendimiento puede caer rápidamente, y finalmente que pueden presentarse conflictos frecuentes.

Durante un fallo del Pool de Aplicación que ejecuta su aplicación ASP, este archivo de bloqueo puede quedar "huérfano". Su presencia indica entonces un cierre incorrecto, y impide el acceso exclusivo. También le impide típicamente escribir/sobrescribir el archivo de base de datos vía FTP, porque se considera "bloqueado" (locked).

Access no está diseñado para la concurrencia real. Este archivo de bloqueo es un paliativo para permitir simularla en condiciones de bajo tráfico, pero en realidad constituye un bloqueo "tosco" extremadamente sensible a las interrupciones de red y con una ausencia casi total de tolerancia a fallos.

Si debe eliminar un archivo .ldb o .laccdb residual:

•  No lo elimine nunca mientras la base esté abierta
•  No copie una base mientras exista un .ldb
•  Si la eliminación es imposible:
  • En un alojamiento compartido: debe reciclar el Pool de Aplicación desde Plesk en la pestaña « Hosting & DNS > Dedicated IIS Application Pool for Website », y luego esperar varios minutos a que se libere el acceso al archivo: o bien desaparecerá por sí mismo, o bien deberá (y por fin podrá) eliminarlo manualmente.
  • En un servidor dedicado: puede matar directamente el proceso w3wp.exe asociado a su Pool de Aplicaciones IIS: el archivo será liberado y podrá eliminarlo inmediatamente. El acceso a la base también será posible, lo que le permitirá sobrescribirla vía FTP si es necesario.

Los archivos de locking residuales y huérfanos muy frecuentes son indicios de que el Pool de Aplicación IIS ha fallado. Entonces es momento de examinar su código fuente o el schema de la base para comprender por qué. También debe considerarse una migración hacia un sistema de bases de datos más robusto como MariaDB si encuentra con demasiada frecuencia este tipo de problemas.

Migración hacia MariaDB

Puede ocurrir que alcance de una manera u otra los límites de Microsoft Access. En ese momento se plantea la cuestión de migrar hacia un sistema de base de datos más robusto. La solución que podría parecer la más evidente a primera vista sería Microsoft SQL Server. Sin embargo, este producto es extremadamente diferente de Access, y realmente mucho más complejo de dominar, además de tener un coste de licencia considerable. Por estas razones, lo proporcionamos únicamente en nuestros servidores dedicados. Una transición hacia MariaDB es más adecuada en la mayoría de los casos.

Migrar de Microsoft Access a MariaDB se vuelve pertinente en cuanto su aplicación revela los siguientes síntomas: escrituras concurrentes fiables no bloqueantes, escalado dificultoso, necesidad de copias de seguridad y restauraciones fiables, exigencias de disponibilidad, o voluntad de salir de los límites estructurales de Access (tamaño, bloqueo, riesgo de corrupción).

MariaDB aporta un verdadero motor servidor, transacciones robustas y funcionalidades de acceso y copia de seguridad eficaces, manteniéndose sencillo de utilizar cuando se tiene experiencia con Microsoft Access. La gestión de la concurrencia y de cientos de conexiones o consultas simultáneas es absolutamente incomparable.

El sesgo frecuente consiste, no obstante, en creer que un simple cambio de motor bastará. En realidad, no se trata de un simple "export/import", sino de una revisión controlada de los datos, las consultas y el proceso de explotación. Una migración de motor de bases de datos implica un cambio del modelo de ejecución (archivo local frente a servidor). Por tanto, impacta el esquema, las consultas y el código ADO. Sin embargo, una vez importados los datos y ajustadas sus consultas, un cambio de Driver ODBC suele ser la última etapa requerida.

Dominamos la metodología que debe seguirse para efectuar tal migración de forma gradual y sin interrupción de producción de su sitio ASP. Consiste principalmente en evaluar las tablas, relaciones, índices, consultas guardadas, reglas de validación, campos calculados, macros y, por último, las consultas SQL específicas Jet/ACE que habrá que reescribir parcialmente para ajustarlas al estándar SQL.

Durante el diseño del esquema objetivo en MariaDB (tipos, claves primarias, restricciones, índices), conviene tratar las divergencias con Access, como por ejemplo AutoNumber que pasa a ser AUTO_INCREMENT, Si/No que pasa a ser TINYINT(1) o BOOLEAN, o incluso Fecha/Hora que pasa a ser DATETIME/TIMESTAMP.

Los campos de tipo Attachment/OLE ya están desaconsejados con Microsoft Access, como en cualquier SGBD. Esta migración es la ocasión de replantearlos, a menudo almacenando los datos binarios en un archivo en el disco. También es la ocasión de corregir los antipatrones frecuentes en Access, tales como la ausencia de claves, los tipos demasiado permisivos o los datos multivalor; migrar de forma idéntica no haría más que transferir problemas de schema.

Durante tales migraciones somos particularmente atentos a la sintaxis específica del SQL y de la lógica aplicativa del lado ASP o de las consultas guardadas. Jet/ACE y MariaDB no tienen el mismo dialecto (ej. funciones de fecha, concatenación, IIf, Nz, LIKE, TOP, parámetros, gestión de nulls). Para cada consulta crítica conviene escribir su equivalente en SQL estándar compatible con MariaDB, y luego validar los resultados sobre un conjunto de datos fijo.

Del lado Classic ASP, las cadenas de conexión OLE DB Access deberán ser reemplazadas por el Driver ODBC MariaDB. Conviene prestar atención al cambio de semántica transaccional, en particular los cursores ADO: lo que "parecía funcionar" con Access (bloqueos implícitos) debe volverse explícito con rs.CursorType para fiabilizar el funcionamiento de su código ASP.

Por último, la fase de transferencia de datos se aborda en dos tiempos: extracción desde Access hacia un formato intermedio (CSV o TSV) y luego importación en MariaDB con un control estricto de las codificaciones UTF-8, los formatos de fecha y los valores nulos. Deben realizarse controles de integridad, como por ejemplo recuentos de líneas, sumas de control, muestreo de líneas y verificación de restricciones. Si el cambio directo de Access a MariaDB no es viable, prevea una fase de doble escritura o de sincronización.

También nos cuidamos de prever planes de retorno atrás (rollback), conservando en el código ASP las antiguas consultas compatibles con Access, y operamos el cambio operativo de manera planificada y estructurada.

Recuerde finalmente que, sea cual sea el sistema de base de datos, ninguno de ellos sabe eliminar los problemas procedentes del propio código ASP o del schema (consultas no indexadas, ausencia de parámetros, lógica de negocio arriesgada): ¡todo esto corresponde al papel del arquitecto de software que usted es!
(¡y que nosotros también somos!)

Alojamiento ASP Classic

Alojamiento ASP Classic y migración a Windows Server 2025 / 2022 / 2019

Mantenimiento y desarrollo ASP Classic

Mantenimiento, soporte y desarrollo de sitios y aplicaciones ASP Classic

Auditoría y configuración de IIS

Auditoría y mejora de la configuración de Microsoft® IIS