Conectar Access vía ODBC y sincronizar con Google Sheets: guía completa y opciones para pymes

Si trabajas en una pyme que vive en Google Workspace y te estás planteando montar una base de datos en Microsoft Access, seguramente te preguntas cómo acercar ambos mundos sin hacerlo todo a mano. Conectar Access con Google Sheets mediante ODBC y evitar quebraderos de cabeza con la Nube es posible, pero conviene conocer los límites, los pasos y las alternativas reales para no acabar con archivos en conflicto o procesos manuales eternos.

En esta guía reunimos, reorganizamos y explicamos todo lo relevante que publican las fuentes más posicionadas sobre el tema: cómo importar o vincular hojas de cálculo de Google en Access con un controlador ODBC, qué pasa cuando solo tienes Google Drive para compartir, por qué los sincronizadores como Drive o Dropbox no sirven para un back-end multiusuario, y qué soluciones hay para compartir Access por Internet (Dataprius, MapDrive, VPN, servidor Windows, SharePoint) o dar el salto a un servidor de bases de datos (SQL Server o MySQL) manteniendo los formularios de Access.

Qué se puede y qué no se puede hacer entre Access y Google Sheets

La vía soportada y estable para que Access hable con Google Sheets es a través de un controlador ODBC específico para Sheets y un DSN configurado en Windows. Access permite tanto importar datos como vincular tablas externas vía ODBC, lo que te deja traer la información o mantenerla enlazada para trabajar en tiempo (casi) real. Las pruebas documentadas abarcan Access 2003, 2007, 2010, 2013, 2016 y 2019, con comportamiento muy similar en la experiencia de importación y de tablas vinculadas.

Cuando no hay ODBC o no se puede instalar por no tener permisos de administrador, mucha gente intenta un rodeo: enlazar Google Sheets a Excel y después vincular ese Excel a Access. Eso funciona, pero tiene un inconveniente enorme: los cambios de Sheets no llegan a Access salvo que fuerces la actualización del Excel intermedio de forma manual. Si buscas automatización de verdad, necesitas ODBC o plantear otra arquitectura, por ejemplo integrando procesos con Power Automate.

Un apunte útil de contexto: en guías recientes (actualizadas en diciembre de 2024) verás menciones de compatibilidad de navegador; Microsoft recomienda usar Edge para las últimas características y soporte. No afecta al conector ODBC como tal, pero es algo a tener en cuenta si accedes a documentación o asistentes web vinculados.

Conectar Access con Google Sheets mediante ODBC: preparar el terreno

Antes de tocar Access, necesitas un origen de datos ODBC para Google Sheets configurado en el equipo. Ese DSN será el puente entre tus hojas en la Nube y Access. Los controladores ODBC comerciales para Google Sheets documentan este escenario y confirman compatibilidad con las versiones modernas de Access. Una vez listo el DSN, podrás elegir entre importar los datos (copiarlos a Access) o vincularlos (mantenerlos donde están y trabajar vía enlace).

Ventajas de cada enfoque: si importas, te llevas una foto de los datos a tu base de Access y trabajas más rápido, sin depender de la conexión; si vinculas, sigues viendo lo que hay en Sheets, pero estás sujeto a la latencia y a las restricciones de edición y bloqueo propias del origen externo.

Importar datos de Google Sheets a Access usando ODBC

La importación crea tablas locales nuevas en Access con el contenido de tus hojas. Este método es ideal para análisis, informes, o para usar Access como ETL ligero. Los pasos, con Access 2019 como referencia, son los siguientes (idénticos o muy similares en versiones anteriores):

1. Abre tu base de datos en Microsoft Access.
2. Ve a la pestaña «Datos externos» de la cinta.
3. En «Nueva fuente de datos», elige «Desde otros orígenes» y luego «Base de datos ODBC».
4. En el cuadro «Obtener datos externos – Base de datos ODBC», selecciona «Importar el origen de datos a una tabla nueva de la base de datos actual» y pulsa Aceptar.
5. En «Seleccionar origen de datos», abre la pestaña «Origen de datos de equipo».
6. Selecciona el DSN que ya configuraste para Google Sheets y confirma.
7. Marca las tablas u hojas que quieras importar y continúa.
8. Si todo va bien, Access te lo indicará. Puedes marcar «Guardar pasos de importación» para reutilizar el proceso más adelante con un clic. Esto acelera cargas periódicas si trabajas con el mismo origen.
9. Verás las tablas importadas en el panel de navegación. Abre la que necesites para comprobar los datos.

Ten presente que, al importar, las futuras ediciones en Google Sheets no se reflejan automáticamente en Access. Si quieres datos frescos, repite la importación (o automatiza con el propio asistente guardado si procede).

Vincular Google Sheets en Access a través de ODBC

Si prefieres trabajar «en vivo», la vinculación crea tablas enlazadas a tus hojas de Google. Accederás a los datos remotos como si fueran tablas de Access, con sus limitaciones. El procedimiento es:

1. Abre tu base de datos en Access.
2. En «Datos externos», elige «Nueva fuente de datos» → «Desde otros orígenes» → «Base de datos ODBC».
3. En «Obtener datos externos – Base de datos ODBC», marca «Vincular al origen de datos creando una tabla vinculada».
4. En «Seleccionar origen de datos», usa «Origen de datos de equipo» y elige el DSN de Google Sheets.
5. En «Vincular tablas», marca las hojas/tablas que quieras enlazar y continúa.
6. Cuando aparezca «Seleccionar identificador de registro único», elige el campo (o combinación de campos) que identifique de forma única cada fila. Lo más seguro es usar la clave primaria definida en la hoja base para evitar inconsistencias.
7. Las tablas vinculadas aparecerán en el panel. Ábrelas para validar que ves el contenido correcto.

Este método resulta cómodo para consulta y, en algunos casos, para edición acotada. La solidez dependerá del controlador ODBC, del diseño de la hoja y de la conectividad. Si notas lentitud o bloqueos, considera importar o migrar a un motor de base de datos pensado para múltiples usuarios.

¿Automatizar con Excel en medio? Pros, contras y el papel de ODBC

Algunas empresas, por costes, viven en Google Docs/Sheets y solo quieren Access para formularios e informes. El «puente Excel» (Sheets → Excel vinculado → Access vinculado) funciona pero no se refresca solo: hay que actualizar manualmente el Excel para que Access vea cambios nuevos. Si tu objetivo es automatización real, necesitas poder instalar y usar un ODBC para Google Sheets con un DSN; sin permisos de administrador, esta vía suele quedar bloqueada.

Resumiendo la casuística habitual que se ve en foros y documentación: Copilot u otros asistentes pueden sugerir el doble salto con Excel, pero no evita el cuello de botella. En la práctica, o bien instalas el ODBC y vinculas directamente, o bien replanteas la arquitectura (por ejemplo, migrando las tablas a un servidor SQL y dejando Sheets como entrada/consulta, no como fuente primaria).

Google Drive, Dropbox y por qué Access no «vive» bien en sincronizadores

Compartir un archivo de Access en la Nube como si fuera un documento de Word no funciona en escenarios multiusuario. Access está pensado para redes locales (LAN) sobre SMB, donde la unidad compartida se comporta casi como un disco interno. Los sincronizadores (Drive, Dropbox, etc.) copian archivos y resuelven cambios por versiones; cuando dos usuarios abren o modifican a la vez, aparecen conflictos y «copias en conflicto». En el mejor de los casos perderás cambios; en el peor, corromperás el fichero.

Aunque separar front-end y back-end es una buena práctica, colocar el back-end de Access en una carpeta sincronizada acabará provocando pérdidas de registros o conflictos. Incluso si inicialmente «parece ir», tarde o temprano romperá. Esta realidad la reconocen los propios proveedores de sincronización y se cita con frecuencia en sus foros de soporte.

¿Y si no hay red local? Opciones realistas para una pyme con pocas máquinas

Escenario típico: dos o tres ordenadores sin servidor ni switch, todo compartido en Google Drive. Si quieres que varias personas usen Access con un back-end compartido, necesitas un recurso SMB accesible por todos a la vez. Hay tres caminos básicos en coste y complejidad:

• Red local simple: un router o switch barato, equipos en la misma subred, carpeta compartida en Windows con permisos, y mapeo como unidad de red. Es la opción más económica y directa.
• Unidad mapeada en la Nube con SMB real (p. ej., MapDrive de servicios tipo Dataprius): expone una letra de unidad vía Internet como si fuera la LAN. Soluciona conflictos de archivo al ser multiusuario, pero su rendimiento depende de tu conexión.
• Infraestructura remota (VPN o servidor Windows en Cloud): más flexible y «empresarial», pero con mayor coste y administración.

¿Se puede «tirar un cable» entre dos PCs y mapear una partición? Técnicamente sí, creando una conexión directa y compartiendo una carpeta por SMB, pero es frágil, poco escalable y dependiente de la configuración de cada equipo. Mucho más estable (y barato, a la larga) es usar un pequeño router/switch y configurar la red local correctamente.

Cómo mapear una unidad compartida entre dos ordenadores con Windows

Sin entrar en detalles de versiones, el patrón es siempre parecido: comparte una carpeta en el equipo que hará de «servidor» y asígnale permisos; en el otro equipo, mapea esa carpeta como unidad de red. El mapeo expone la ruta compartida con una letra de unidad para que Access la use como back-end. Si solo tienes dos PCs, puedes compartir por SMB con IPs fijas; con varios, añade un router básico y DHCP.

Consejos prácticos: usa rutas UNC (\\equipo\carpeta) en lugar de letras locales en tus enlaces de Access, documenta usuarios y permisos, y evita suspender el «servidor» mientras otros trabajan. Una red estable es la base para que Access multiusuario funcione bien.

Dataprius y MapDrive: acceso multiusuario sin conflictos

Frente a los sincronizadores, hay servicios en la Nube que no replican archivos, sino que exponen acceso multiusuario con bloqueo. Dataprius, por ejemplo, impedirá la edición simultánea del mismo fichero y mostrará un aviso de «archivo en uso». Es una manera de evitar copias en conflicto sin montar una red local clásica.

Si añades su unidad mapeada (MapDrive), obtienes un comportamiento muy similar a un recurso SMB de la LAN, pero sobre Internet. El precio a pagar suele ser la latencia: con ficheros pequeños y buena conexión, va perfecto; si el back-end de Access crece o la línea es floja, notarás lentitud. Merece la pena probar con tus propios datos y carga real.

VPN o servidor Windows en la Nube: más control, más mantenimiento

Una VPN extiende tu red local por Internet y te deja mapear carpetas remotas como si estuvieran en la oficina. Es potente, pero más costosa de implantar y mantener. Requiere conocimientos, equipos y, a menudo, soporte del proveedor Cloud si se integra con servicios como Azure.

La alternativa es contratar un servidor Windows en un proveedor con buenas prácticas de seguridad y, desde ahí, exponer escritorio remoto o montar carpetas compartidas para el back-end de Access. Evita abrir servidores locales a Internet «a pelo» por los riesgos evidentes. Con escritorio remoto, los usuarios trabajan dentro del servidor y se minimizan los problemas de latencia y bloqueo.

SharePoint: posible, pero con transformación y curva de aprendizaje

El ecosistema Microsoft ofrece SharePoint para documentos y flujos de trabajo en la Nube. Se puede trabajar con bases de datos Access en SharePoint, aunque no es un uso directo: requiere transformaciones y adaptaciones que añaden complejidad. Es una opción válida si ya estás en Microsoft 365 y aceptas su curva y sus costes.

Dar el salto: tablas en SQL Server o MySQL con formularios de Access

Una solución muy robusta para multiusuario es mantener el front-end de Access (formularios, consultas, informes) y migrar las tablas a un servidor de bases de datos: SQL Server o MySQL. Luego vinculas esas tablas desde Access vía ODBC y listo.

Con SQL Server tienes dos caminos: un servidor Windows en Cloud con SQL Server instalado o usar Azure SQL Database como servicio gestionado. Este último te quita de encima mantenimiento y seguridad del sistema operativo, a cambio de un coste mensual que puede ser relevante.

Con MySQL el enfoque es similar. Contratas un servicio de base de datos (o un hosting donde puedas instalar MySQL, mejor en Linux), creas el esquema y vinculas en Access mediante un conector ODBC de MySQL. A nivel de rendimiento y escalabilidad, vas a notar una mejora enorme frente a un back-end Access tradicional.

Actualizar el DSN/ODBC de tablas vinculadas en Access con VBA

En entornos donde cambian IPs, credenciales o servidores, es útil poder reenganchar de golpe todas las tablas vinculadas. Access permite automatizar el «reajuste» del DSN de las tablas enlazadas con VBA. La idea es crear un módulo con una función (por ejemplo, cambiarDSNTodasTablas()), una macro que la invoque y un formulario con un botón para lanzar el proceso.

El flujo típico es: desde el formulario, introduces la nueva cadena ODBC (por ejemplo, ‘ODBC;DSN=FACTURACION;UID=usufacturas;PWD=contraseña;DBQ=BDFACTURAS’) y pulsas el botón que llama a la macro. El código recorre todas las tablas de Access, detecta las vinculadas y actualiza su propiedad Connect. Al finalizar, informa de cuántas se han reajustado correctamente.

Si quieres inspeccionar las conexiones vigentes, puedes mostrar las tablas del sistema (p. ej., MSysObjects) y examinar el campo Connect para ver cómo quedó el DSN de cada vínculo. Es una manera segura y verificable de mantener «atadas» las tablas cuando cambian parámetros.

Compatibilidad de versiones y notas de soporte

La conexión con Google Sheets vía ODBC se ha documentado en Access 2003, 2007, 2010, 2013, 2016 y 2019, con comportamiento coherente. El requisito común es tener el DSN del controlador de Google Sheets correctamente instalado y configurado. En guías corporativas verás avisos de navegador no soportado y llamadas a usar Microsoft Edge para soporte moderno; no afecta a ODBC, pero recuerda mantener el sistema actualizado.

Queda un mensaje claro: si trabajas con pocos usuarios y datos livianos, ODBC con tablas vinculadas o importadas desde Google Sheets te saca del paso; si escalas en usuarios o volumen, migra a SQL Server/MySQL y usa Access como front-end. Evita sincronizadores para back-ends compartidos, arma una red SMB estable (local o mapeada en la Nube) o valora soluciones como escritorio remoto o servicios multiusuario sin conflictos.