Cuando un archivo .accdb viaj a por un túnel VPN cada clic se convierte en espera, y un simple micro‑corte amenaza con corromper datos críticos de la empresa. A continuación verás por qué sucede, cómo medirlo y, sobre todo, qué soluciones aplicar — desde un “split” inmediato hasta la migración definitiva a SQL Server o Escritorio Remoto— para que Access vuelva a rendir con seguridad y velocidad.

Contexto de la empresa y síntomas

Diez usuarios comparten varias bases de datos Access alojadas en una carpeta SMB junto a QuickBooks y otros documentos. En la sede local todo “parece ir bien”, pero:

• Al conectarse por VPN los formularios tardan minutos en abrir.
• Las tablas vinculan campos en blanco o devuelven errores “Record is deleted”.
• Se producen corrupciones y compactaciones forzadas casi a diario.
• Los bloqueos optimistas (record locking) fallan, generando duplicados.

El mapa de red muestra saltos de 40 – 120 ms, 10 – 100 veces más que en LAN. El creador original ya no está; la aplicación, sin documentación formal, se ha vuelto misión‑crítica.

Mecanismo de Access que provoca la lentitud

Access es un motor file‑based que intercambia páginas de 4 KB con el fichero .accdb por cada operación: cargar un formulario, aplicar un filtro, recorrer un subformulario de detalle, etc. En LAN esto viaja a 1 Gbps con latencias <10 ms, pero a través de VPN:

1. Cada página sufre latencia de ida y vuelta (RTT) multiplicada por cientos de I/O.
2. SMB firma paquetes y agrega overhead de cifrado VPN.
3. Cualquier micro‑corte rompe la secuencia de bandeo y deja el fichero en estado inconsistente.

En resumen, el tráfico de Access es chatty: muchas operaciones pequeñas y secuenciales. Exactamente lo contrario de lo que tolera una WAN con latencia.

Riesgos de corrupción y pérdida de datos

A diferencia de SQL Server, Access no dispone de un registro de transacciones (write‑ahead log) capaz de revertir páginas dañadas. Si la conexión se interrumpe durante un commit:

• El archivo queda “a medio guardar” y Access obliga a compactar.
• En el mejor de los casos se pierden los cambios de la última sesión; en el peor, la copia de seguridad es la única salvación.
• El bloqueo compartido (.laccdb) puede persistir, impidiendo abrir la BD hasta eliminarlo manualmente.

Cómo medir la gravedad (latencia y throughput)

Antes de decidir conviene cuantificar:

Prueba	Objetivo	Umbral aceptable
ping <Servidor>	RTT medio	<10 ms (LAN) / <40 ms (RDS)
iperf3	Throughput TCP	>100 Mbps sostenidos
Contador “Pages/sec” en Access	Páginas leídas por segundo	<80 en WAN
Tiempo de apertura de formulario pesado	Simula uso real	<2 s en LAN / RDS

Si los valores exceden los límites es casi imposible que Access funcione bien sin cambiar la arquitectura.

Soluciones comparadas

Enfoque	Ventajas	Desventajas / Requisitos
Dividir la base (Front‑End local, Back‑End en servidor LAN)	Rápido y gratis; reduce riesgo de corrupción dentro de la sede.	No mejora la VPN; sigue habiendo tráfico masivo de archivos.
Migrar Back‑End a SQL Server Express	Modelo cliente‑servidor; minimiza tráfico; escalable; sin coste de licencias hasta 10 GB.	Ajustar tablas, consultas y VBA; requiere conocimientos de upsizing y ODBC.
Remote Desktop / Terminal Services	La BD permanece en LAN; solo se envían píxeles; rendimiento casi local; corrupción virtualmente nula.	Licencias RDS/Windows Server; hardware para varias sesiones; Access sigue siendo el motor.
Hospedaje en la nube + SQL (PaaS)	Alta disponibilidad y copias de seguridad automáticas; acceso global.	Coste mensual; depende de internet; mismos cambios que con SQL on‑prem.
Reescritura Web / API REST	Acceso vía navegador o app móvil; desacopla datos y presentación.	Proyecto de mayor alcance; curva de aprendizaje; no reutiliza el FE.

Estrategia inmediata: Split y copias de seguridad

No esperes a “la” migración perfecta. Ejecuta el Database Splitter de Access:

1. Coloca el Back‑End .accdb solo en la LAN, nunca en carpetas sincronizadas (OneDrive, Dropbox).
2. Copia el Front‑End a cada PC y programa un script de actualización (robocopy + fecha) para desplegar versiones.
3. Activa copias VSS del servidor cada hora y una copia fuera de línea diaria. Así, si se corrompe, el retroceso es rápido.

Migrar a SQL Server Express paso a paso

1. Inventario y limpieza: elimina tablas huérfanas, normaliza claves, defina relaciones e índices.
2. Upsizing: utiliza el asistente “Microsoft SQL Server Migration” o scripts SSMA para crear tablas e importar datos.
3. ODBC: crea un DSN de sistema con SQL Server Native Client; configura autenticación Windows.
4. Relink: en Access ve a External Data > Linked Table Manager y apunta a las tablas SQL.
5. Optimiza: convierte consultas complejas a pass‑through, usa procedimientos almacenados y carga diferida de subformularios para reducir llamadas.
6. Pruebas piloto: dos usuarios clave validan durante una semana; registra métricas de tiempo.
7. Corte oficial: respalda .accdb, actualiza rutas ODBC en todos los FE y deshabilita el antiguo archivo.

Cuando Remote Desktop es la mejor opción

Si no hay recursos para migrar código y se dispone ya de un servidor Windows:

• Instala el rol Remote Desktop Session Host.
• Crea colecciones y publica Access Runtime o la versión completa con licencia.
• Los usuarios inician un archivo .rdp; el FE se ejecuta dentro del servidor, con acceso local al Back‑End.
• La VPN puede incluso desaparecer si publicas RDP sobre HTTPS (Gateway) con MFA.

Buenas prácticas de Access + ODBC

• Evita tablas vinculadas que muestren miles de registros de golpe; utiliza forms desconectados o paginados.
• Carga listas desplegables (combos) a demanda con consultas TOP 500.
• Aplica dbSeeChanges en DAO/ADO cuando modifiques tablas con identificadores de fila.
• Comprueba el plan de ejecución en SQL Server (Actual Execution Plan) y añade índices compuestos.
• Configura IdleTimeout y Connection Lifetime para reciclar conexiones muertas.

Costes y licenciamiento orientativos

Elemento	Opción económica	Opción empresarial
SQL Server	Express (0 €)	Standard 2‑Core – ≈ 3 700 € perpetua
Remote Desktop CALs	N/A	≈ 100 € / usuario
Servidor físico	Torre i5, 32 GB RAM ≈ 1 200 €	Rack Xeon, RAID, 128 GB ≈ 4 000 €
Azure SQL Database	Basic 5 DTU ≈ 5 €/mes	P1V5 ≈ 350 €/mes

En la mayoría de pymes la combinación SQL Server Express + servidor de torre existente cubre 3 – 5 años de crecimiento sin cuotas mensuales.

Plan de continuidad y copias de seguridad

• Activa Windows Server Backup con destino externo rotatorio cada noche.
• En SQL Server programa FULL y DIFF más LOG cada 15 min. Conserva al menos 30 días.
• Ensaya restauraciones en un servidor aislado cada trimestre.
• Documenta rutas, credenciales de servicio y pasos de emergencia en un archivo offline.

Preguntas frecuentes

¿Por qué no usar OneDrive para compartir el .accdb? OneDrive sincroniza “chunks” diferidos; dos usuarios abren la BD sin notarlo y la corrupción está servida. ¿Cuántos usuarios aguanta Access en LAN? Hasta 20 – 25 con FE dividido y red Gigabit, siempre que las consultas estén optimizadas. ¿SQL Express tiene límite de conexiones? No; comparte el mismo motor que la edición Standard. El límite real es CPU (4 cores lógicos) y 10 GB de datos. ¿Puedo seguir usando formularios Access tras migrar a SQL? Sí; el Front‑End apenas cambia. Solo deberás revisar VBA que haga CurrentDb.Execute "DELETE …" y añadir parámetros ODBC. ¿Cuánto tarda la migración típica? Para una BD de 200 MB y 25 tablas: dos días de preparación, una tarde de corte y una semana de monitorización. ¿Qué pasa si la VPN se cae con RDS? La sesión puede reconectar; el proceso de Access sigue en el servidor, no hay riesgo de corrupción.

Conclusión

El cuello de botella no es Access en sí ni el hardware de los PC, sino el hecho de abrir un archivo monolítico a través de una VPN de alta latencia. La solución consiste en acercar la lógica al servidor por dos caminos probados:

1. Remote Desktop para un quick‑win con mínimas modificaciones.
2. SQL Server Express (o equivalente en la nube) para un modelo cliente‑servidor robusto y escalable.

Empieza ya dividiendo la base y trazando un plan de migración; tu contabilidad y tus datos dejarán de depender de la suerte cada vez que alguien haga clic desde casa.