Error en base de datos de access, el archivo esta en uso
Espero que alguien me pueda colaborar con el siguiente tema.
Tengo una base de datos divida en cliente y servidor, el servidor aloja todas las tablas mientras que la cliente tiene consultas, formularios, informes y las tablas vinculadas de la servidor. Estaba funcionando muy bien pero ahora al cerrar la aplicación arroja el siguiente error.
Compacto y reparo tanto la cliente como la servidor, pero sigue arrojando el error al cerrar. He estado investigando y he encontrado muchas opciones como por ejemplo que la carpeta donde esta alojada la base este compartida con permisos de lectura y escritura, que la base de access sea modo compartido y no exclusivo, reviso todas estas posibles opciones y no logro solucionar el problema.
2 Respuestas
Paso uno: eliminar de forma temporal la compartición de ese archivo (así romperá vínculos que ya no existen en la práctica).
Paso dos: compactar la base.
Probablemente se esté generando una copia al no poder cerrar la compartida, por eso lo primordial es borrar ese vínculo falso (el Ldb se dejará borrar cuando esté liberada).
Paso tres: volver a compartirla.
¡Gracias! Enrique. He realizado lo que mencionss pero sigue arrojando el problema. Se me ha olvidado mencionar que la cliente se ejecuta en un servidor y los pc tienen instalado runtime de access.
Analizando la respuesta del error, me llama la atención 'esa' ruta en la que parece que está en la nube del usuario (su OneDrive), Access y 'la nube' no se llevan bien, para utilizar ese entorno están las aplicaciones externas o intentos más o menos logrados con Azure y otros, lo adecuado sería utilizar SQL Server o su versión gratuita (SQL Express).
Access en un entorno virtual en la nube, permite un solo usuario concurrente, utilizar la aplicación compartida requiere demasiados recursos del servidor y los proveedores los limitan (son muy caros).
Aconsejo dejar la base (la MDB) en una carpeta compartida en el servidor y darles a los clientes la dirección del recurso compartido (que nunca sería el 'C' local) sino algo como;
\\Nombre-Servidor\ ........ ruta al recurso compartido si hay más de una carpeta a partir de esa raiz ....
Si la base es accesible (se accede a los datos) haría una importación en una nueva base y estabilizaría el entorno antes de compartirlo, que los clientes utilicen el runtime no les influye para trabajar de forma correcta, para ellos el recurso remoto es una unidad de disco (que no es local).
Ya lo he realizado compartiendo una carpeta en el servidor, incluso se creo una unidad "z" y ocurre lo mismo.
Solo ocurre el error al cerrar la base, por lo demás el sistema funciona bien.
La unidad virtual (la Z que se crea) se creara en los clientes, en el servidor no tendría sentido.
¿Se está accediendo a la base desde la consola del servidor?, si es funcional y solo da el problema al cerrarla, es posible que tenga un proceso en ese evento para que se auto-compacte (y para ello requiere que no tenga usuarios con archivos abiertos).
Por seguridad, crearía una nueva base, importaría las tablas (si se importan en el mismo paso, respeta las relaciones) y si hay algún problema con los datos al hacer la importación lo delatara.
Buenos días, perdona la demora.
He realizado una nueva copia, importando tablas, consultas, formularios, informes, etc. y no presento problema alguno.
La he estado ejecutando localmente (disco c) y sigue arrojando el mismo problema
Ese problema solo se puede 'ver' en la aplicación real.
Basta que se abra un recordset para hacer un proceso paralelo desde el formulario activo, para que 'aparezca' otro usuario.
Si el acceso paralelo a los datos es en modo lectura, no interfiere en el cierre de la aplicación, pero si se abre en modo edición (lectura + escritura) y no se cierra adecuadamente, aparece el problema al intentar cerrar la aplicación.
Buenos días
Perdona pero no soy muy experto en el tema, ¿cómo debo hacer lo que mencionas?
Lo esencial es ver (en el servidor) si el archivo de bloqueo anteriormente mencionado ([nombre-aplicación].Ldb o [nombre-aplicación].laccdb) existe (que existirá) y mismo con el Block de notas ver su contenido.
Si eres el creador de la aplicación verifica que se completan las tres fases de cualquier proceso:
Nacer (crear el proceso: abrirse) ==> Vivir (manipular el contenido) ==> Morir (cerrar los procesos que creo).
Muchos nacen y viven, pero se resisten a morir (por eso a forzar un cierre se le conoce como: 'matar el proceso')
Estos son los riesgos que se corren cuando se utiliza Access como Front End. Indica que alguno de los usuarios salió en forma anormal de la aplicación. Le recomiendo cuanto antes hacer una copia de la base de datos sino quiere correr riesgos de tal forma que en cualquier momento su base no sea accesible, tuve la experiencia hace unos años de la pérdida total de la información, el origen del problema fue que los pc tenían diferentes versiones de Windows, siendo este una las grandes fallas de Access para entorno multiusuario. Revise si en la carpeta del servidor está abierto el archivo de bloque lbl, en este caso indica que su base datos está bloqueada, ábrala manteniendo presiona la techa shift y compáctela. Por otra parte, no utilice la carpeta users para alojar y compartir la base de datos, hágalo en una partición específica y comparta la carpeta con todos los privilegios.
Como trabaja con aplicación cliente-servidor, le recomiendo migrar su base de datos a un sistema más robusto, personalmente utilizo PostgreSQL como servidor de datos, una de las grandes ventajas es la seguridad y concurrencia, además si piensa migrar a Linux o subir su base datos a la nube ya ha recorrido un gran camino. Si quiere más información al respecto puede contactarme en [email protected]
Perdón anote lbl y la extensión debe ser:
*. Ldb en Access 2003 y en versiones anteriores de Access
*. Laccdb en Access 2007/2010
Si no puede abrir la base datos pruebe importar todas las tablas a otra base datos si no es posible creo que su base de datos esta dañada.
Tenga cuidado con el antivirus McAfee, causa problemas, desactívelo y pruebe nuevamente.