Por qué QuickBooks no puede almacenarse en Google Drive para varios usuarios

Antes de entrar en detalles, es importante comprender que se trata de un concepto general y que en realidad podemos reducirlo a “¿por qué las aplicaciones cliente/servidor o de archivo de base de datos compartido no pueden almacenarse en almacenamiento sincronizado (p. ej. Google Drive, DropBox, NextCloud, etc.) cuando el acceso no está limitado a un único usuario?” QuickBooks utiliza un mecanismo de archivo de base de datos compartido común en las aplicaciones de estilo de los años ochenta, donde un único archivo o conjunto de archivos se comparte mediante un mecanismo de uso compartido de archivos y cada copia individual de la aplicación accede a este archivo para modificarlo. Google Drive es un mecanismo de almacenamiento sincronizado: es decir, realiza copias de los datos de una ubicación a otra. Las personas que trabajan en el mismo archivo al mismo tiempo pueden sobrescribir, y a menudo lo hacen, los cambios de las demás, y la expectativa es que estos cambios se concilien manualmente más adelante, se ignoren, o que los usuarios estén controlados para evitar que trabajen al mismo tiempo.

Para algunos tipos de aplicaciones multiusuario, el almacenamiento sincronizado puede aprovecharse, pero solo en situaciones en las que la aplicación pueda ser bloqueada por el sistema de almacenamiento de modo que solo permita cambios cuando no exista ningún otro. Esto requiere un nivel de integración poco práctico con la sincronización de archivos de uso general. La mayoría de los sistemas que hacen esto utilizan un mecanismo de sincronización integrado en la capa de la base de datos o de la aplicación, no uno de uso general que tenga que funcionar a ciegas. Para mantener la integridad de los datos con almacenamiento sincronizado, es necesario que solo una persona edite un archivo a la vez, esperar a que todos los posibles usuarios reciban las actualizaciones realizadas tras el “guardado” de ese archivo, y entonces un usuario distinto puede editar ese archivo y repetir el proceso. Pero solo un usuario a la vez puede trabajar en el archivo y debe recibir las actualizaciones del otro usuario antes de abrir el archivo para editarlo él mismo. De lo contrario, el sistema tiene que preguntar a los usuarios qué cambios conservar y cuáles descartar en cada caso.

Este proceso de integridad no puede aplicarse a un archivo de base de datos de ninguna manera realista. El archivo está diseñado para estar abierto y accesible todo el tiempo, no solo para abrirse, editarse y guardarse rápidamente. El guardado tampoco es manual ni siempre predecible. Por lo general suponemos que el guardado ocurre de forma continua durante el uso, pero el almacenamiento en caché puede hacer que incluso esas operaciones de guardado resulten imposibles de controlar manualmente. Pero esto es necesario por razones de rendimiento.

La confusión suele surgir porque un único usuario, sin el temor de que otro usuario acceda al sistema al mismo tiempo, puede usar almacenamiento sincronizado, como Google Drive o Apple iCloud, para que actúe como mecanismo de respaldo (sencillamente crea una copia remota de forma automática) o como medio para replicar el archivo, de modo que el único usuario pueda usarlo primero desde una ubicación y luego desde otra sin necesidad de mover manualmente el archivo de un lugar a otro. Siempre que ese único usuario se tome el tiempo suficiente al desplazarse entre ubicaciones para asegurarse de que cualquier caché se haya vaciado y de que las sincronizaciones y los bloqueos se hayan completado, o se asegure de no haber dejado abierta la primera instancia de la aplicación, puede asumir razonablemente que el sistema es seguro (pero no puede garantizarlo por completo: el mecanismo conlleva un riesgo mínimo de condiciones de carrera incluso entonces). Como existe “una forma” de usar de manera segura el almacenamiento sincronizado con la aplicación en modo de un solo usuario, muchos trabajadores contables o financieros sin conocimientos técnicos supondrán incorrectamente que el acceso simultáneo multiusuario, que es algo completamente distinto, también funcionará. Esto, sin embargo, no es posible.

Lo que ocurre es que se produce una condición de carrera entre varios usuarios y nunca se puede estar del todo seguro de que no haya sucedido. A veces los datos sencillamente serán incorrectos y no habrá duda de que se ha producido una condición de carrera, ya que las cifras serán enormemente inexactas. Pero, con mayor frecuencia, algunas transacciones simplemente se perderán incluso después de haber sido revisadas.

Pongamos un ejemplo. El Usuario 1 está en casa e introduce un nuevo recibo en QuickBooks. Este cambio empieza a guardarse en el ordenador local y, una vez completado, comienza a reenviar el nuevo archivo a Google Drive en la nube (en línea). El Usuario 2 está en la oficina y, durante este tiempo, empieza a registrar el pago de un cliente sobre una factura. La copia del archivo de datos de QuickBooks del Usuario 2 está abierta y no puede sobrescribirse mientras está en uso, por lo que la copia que se está enviando a Google Drive no puede llegar al Usuario 2. Una vez que el Usuario 2 guarda su cambio, su copia también quiere enviarse a Google Drive. Google Drive tiene ahora que hacer algo con dos documentos que partían siendo iguales pero que ahora tienen dos cambios radicalmente distintos, sin que ninguna de las copias contenga ambos. No tiene ningún medio posible de fusionarlos, así que puede aceptar al Usuario 1 como maestro y descartar los cambios del Usuario 2 (p. ej. prioridad del primero). O puede aceptar los cambios del Usuario 2 y descartar los del Usuario 1 (p. ej. prioridad del último). O, por supuesto, puede descartar todos los cambios y no aceptar ninguno. En ningún caso se conservan las transacciones financieras de todos los usuarios, incluso después de que las hayan guardado localmente. O bien el Usuario 1 o bien el Usuario 2 (o posiblemente ambos) van a ver cómo datos que creían haber guardado desaparecen de repente. Si se añaden más usuarios, el problema simplemente se agranda.

Parte del problema es que, al trabajar a nivel de acceso a archivos, y al sincronizar y compartir datos a nivel de archivo completo, no hay forma de bloquear solo un registro o fila, ni de mantener las transacciones separadas ni de fusionar los cambios. El archivo es una única entidad y ha cambiado. Es todo o nada. Las aplicaciones individuales de QuickBooks no pueden comunicarse entre sí directamente, ni a través del archivo de base de datos, para coordinar escrituras, guardados, lecturas, etc. y sortear este problema. Están a ciegas y no pueden saber que otras aplicaciones están intentando trabajar con el archivo al mismo tiempo, porque cada una tiene su propia copia única del archivo; no hay nada “compartido” entre ellas que permita la comunicación. Las copias no están vinculadas entre sí, aquí no hay ningún estado cuántico de por medio. Y además podemos sumar los posibles problemas de que una o más instancias de la aplicación se usen cuando hay una conexión a Internet lenta o defectuosa o, peor aún, cuando una instancia está sin conexión. Puede haber horas o días de cambios que tengan que sobrescribir, o ser sobrescritos, cuando finalmente se produzca la sincronización. Rara vez hablamos de milisegundos, sino a menudo de días de datos.

La forma en que se gestiona este problema, cuando se gestiona, mediante archivos compartidos localmente es multifacética. En primer lugar, solo hay un archivo, no copias de ese archivo. Así que todos los cambios están disponibles para todas las copias de la aplicación de forma simultánea e instantánea. Cuando una instancia de la aplicación va a escribir datos en el archivo, utiliza un mecanismo de bloqueo y alerta similar al modo en que los sistemas de archivos en clúster (Clustered File Systems) permiten que funcionen las SAN, donde puede avisar a las demás instancias de la aplicación de que se está realizando un cambio y de que tienen que esperar a que se complete, para luego actualizar su copia de los datos antes de continuar. Solo una instancia puede escribir y todas las demás tienen que esperar. No hay condiciones de carrera porque el bloqueo se obtiene antes de empezar y se libera al terminar. Y todas las instancias solo funcionan mientras los datos estén accesibles en ese momento; si se pierde la conexión, no pueden continuar. Un mecanismo crítico de protección de la integridad de los datos. Algunas aplicaciones llevan este mecanismo a un nivel aún mayor y añaden canales de comunicación directos (en lugar de a través del archivo compartido) para hacer este proceso más rápido y obtener un mejor rendimiento. Pero pocas llegan tan lejos, ya que, una vez que se alcanza ese nivel, por lo general resulta mucho más fácil sencillamente migrar a una aplicación moderna que intentar encajar a la fuerza sistemas multiusuario modernos en diseños de hace décadas.

Esperamos que esto haya aclarado por qué los contables suelen pensar que los archivos sincronizados funcionarán y por qué a menudo afirman que “a mí me funcionó” cuando deberían decir “tuve suerte” o “lo usé en un escenario totalmente distinto que no se aplica a un entorno multiusuario”, y por qué se puede usar perfectamente Google Drive, NextCloud, iCloud, DropBox y más con QuickBooks y otras aplicaciones de estilo heredado para copias de seguridad y transferencias de datos, pero no se puede plantear intentar usarlo como medio para obtener acceso multiusuario, ya que sencillamente no puede mantener los datos intactos.