Warum QuickBooks für mehrere Benutzer nicht auf Google Drive gespeichert werden kann

Bevor wir auf die Einzelheiten eingehen, ist es wichtig zu verstehen, dass es sich hierbei um ein allgemeines Konzept handelt, das wir eigentlich auf die Frage reduzieren können: „Warum können Client/Server- oder Anwendungen mit gemeinsam genutzten Datenbankdateien nicht auf synchronisiertem Speicher (z. B. Google Drive, DropBox, NextCloud usw.) abgelegt werden, wenn der Zugriff nicht auf einen einzelnen Benutzer beschränkt ist?“ QuickBooks verwendet einen Mechanismus mit gemeinsam genutzten Datenbankdateien, wie er für Anwendungen im Stil der 1980er Jahre üblich war, bei dem eine einzelne Datei oder ein Satz von Dateien über einen Dateifreigabemechanismus geteilt wird und einzelne Kopien der Anwendung jeweils auf diese Datei zugreifen, um sie zu ändern. Google Drive ist ein Mechanismus für synchronisierten Speicher: Das bedeutet, dass Kopien von Daten von einem Ort an einen anderen erstellt werden. Personen, die gleichzeitig an derselben Datei arbeiten, können die Änderungen der jeweils anderen überschreiben – und tun dies häufig auch –, und es wird erwartet, dass diese Änderungen später manuell abgeglichen oder ignoriert werden oder dass die Benutzer so gesteuert werden, dass sie nicht gleichzeitig arbeiten.

Bei einigen Arten von Mehrbenutzeranwendungen kann synchronisierter Speicher genutzt werden, jedoch nur in Situationen, in denen die Anwendung vom Speichersystem gesperrt werden kann, sodass Änderungen nur dann zugelassen werden, wenn keine anderen vorhanden sind. Dies erfordert ein Maß an Integration, das mit allgemeiner Dateisynchronisierung nicht praktikabel ist. Die meisten Systeme, die dies tun, verwenden einen Synchronisierungsmechanismus, der entweder in die Datenbank- oder die Anwendungsschicht integriert ist, und keinen Allzweckmechanismus, der blind funktionieren muss. Damit die Datenintegrität bei synchronisiertem Speicher gewahrt bleibt, ist es notwendig, dass jeweils nur eine Person eine Datei bearbeitet, abwartet, bis alle potenziellen Benutzer die nach dem „Speichern“ dieser Datei vorgenommenen Aktualisierungen erhalten haben, und dann ein anderer Benutzer diese Datei bearbeiten und den Vorgang wiederholen kann. Aber es kann immer nur ein Benutzer gleichzeitig an der Datei arbeiten, und er muss die Aktualisierungen des anderen Benutzers erhalten, bevor er die Datei selbst zur Bearbeitung öffnet. Andernfalls muss das System die Benutzer in jedem Einzelfall fragen, welche Änderungen beibehalten und welche verworfen werden sollen.

Dieser Integritätsprozess lässt sich auf eine Datenbankdatei in keiner realistischen Weise anwenden. Die Datei ist darauf ausgelegt, ständig geöffnet zu sein und auf sie zugegriffen zu werden, und nicht nur, um sie kurz zu öffnen, zu bearbeiten und zu speichern. Das Speichern erfolgt zudem nicht manuell und ist nicht immer vorhersehbar. Wir gehen im Allgemeinen davon aus, dass das Speichern während der Nutzung kontinuierlich erfolgt, aber durch Caching kann es sogar unmöglich werden, diese Speichervorgänge manuell zu steuern. Dies ist jedoch aus Leistungsgründen notwendig.

Verwirrung entsteht häufig, weil ein einzelner Benutzer – ohne die Befürchtung, dass ein anderer Benutzer gleichzeitig auf das System zugreift – synchronisierten Speicher wie Google Drive oder Apple iCloud als Sicherungsmechanismus nutzen kann (es wird einfach automatisch eine entfernte Kopie erstellt) und/oder als Mittel zur Replikation der Datei, sodass der einzelne Benutzer sie zunächst von einem Ort und dann von einem anderen verwenden kann, ohne die Datei manuell von Ort zu Ort verschieben zu müssen. Solange dieser einzelne Benutzer sich beim Wechsel zwischen den Standorten genügend Zeit lässt, um sicherzustellen, dass ein etwaiger Cache geleert wurde und Synchronisierungen und Sperren abgeschlossen sind, oder sicherstellt, dass er die erste Instanz der Anwendung nicht geöffnet gelassen hat, kann er vernünftigerweise von einem sicheren System ausgehen (aber nicht vollständig garantieren – selbst dann birgt der Mechanismus ein minimales Risiko von Race Conditions). Da es „einen Weg“ gibt, synchronisierten Speicher mit der Anwendung im Einzelbenutzermodus sicher zu nutzen, nehmen viele nicht-technische Mitarbeiter im Rechnungs- oder Finanzwesen fälschlicherweise an, dass auch der gleichzeitige Mehrbenutzerzugriff, der etwas völlig anderes ist, funktioniert. Das ist jedoch nicht möglich.

Was passiert, ist, dass eine Race Condition zwischen mehreren Benutzern entsteht und Sie sich nie ganz sicher sein können, dass sie nicht aufgetreten ist. Manchmal sind die Daten einfach fehlerhaft, und es besteht kein Zweifel, dass eine Race Condition aufgetreten ist, da die Zahlen völlig ungenau sind. Häufiger jedoch gehen einige Transaktionen einfach verloren, selbst nachdem sie überprüft wurden.

Nehmen wir ein Beispiel. Benutzer 1 ist zu Hause und gibt einen neuen Beleg in QuickBooks ein. Diese Änderung wird zunächst auf dem lokalen Computer gespeichert, und nachdem dies abgeschlossen ist, beginnt die Weiterleitung der neuen Datei an Google Drive in der Cloud (online). Benutzer 2 ist im Büro und beginnt in dieser Zeit, eine Kundenzahlung zu einer Rechnung einzugeben. Die Kopie der QuickBooks-Datendatei von Benutzer 2 ist geöffnet und kann während der Nutzung nicht überschrieben werden, sodass die an Google Drive gesendete Kopie Benutzer 2 nicht erreichen kann. Sobald Benutzer 2 seine Änderung speichert, möchte auch seine Kopie an Google Drive gesendet werden. Google Drive muss nun etwas mit zwei Dokumenten anfangen, die anfangs identisch waren, nun aber zwei grundlegend unterschiedliche Änderungen aufweisen, wobei keine der beiden Kopien beide enthält. Es gibt keine Möglichkeit, sie zusammenzuführen, sodass entweder Benutzer 1 als Master akzeptiert und die Änderungen von Benutzer 2 verworfen werden (z. B. Priorität für die erste Version) oder die Änderungen von Benutzer 2 akzeptiert und die Änderungen von Benutzer 1 verworfen werden (z. B. Priorität für die neueste Version). Oder es können natürlich alle Änderungen verworfen und keine akzeptiert werden. In keinem Fall bleiben die Finanztransaktionen aller Benutzer erhalten, selbst nachdem sie diese lokal gespeichert haben. Entweder Benutzer 1 oder Benutzer 2 (oder möglicherweise beide) werden plötzlich feststellen, dass Daten, die sie für gespeichert hielten, verschwunden sind. Fügt man weitere Benutzer hinzu, wird das Problem nur noch größer.

Ein Teil des Problems besteht darin, dass es beim Arbeiten auf Dateizugriffsebene und beim Synchronisieren und Teilen von Daten auf der Ebene ganzer Dateien keine Möglichkeit gibt, nur einen einzelnen Datensatz oder eine einzelne Zeile zu sperren, Transaktionen getrennt zu halten oder Änderungen zusammenzuführen. Die Datei ist eine einzige Einheit, und sie hat sich geändert. Es gilt das Alles-oder-Nichts-Prinzip. Die einzelnen QuickBooks-Anwendungen können weder direkt noch über die Datenbankdatei miteinander kommunizieren, um Schreibvorgänge, Speichervorgänge, Lesevorgänge usw. zu koordinieren und dieses Problem zu umgehen. Sie sind blind und können nicht wissen, dass andere Anwendungen gleichzeitig versuchen, mit der Datei zu arbeiten, da jede ihre eigene, eindeutige Kopie der Datei hat; es gibt nichts „Gemeinsames“ zwischen ihnen, das eine Kommunikation ermöglichen würde. Die Kopien sind nicht miteinander verbunden, hier ist kein Quantenzustand im Spiel. Und dann können wir noch die möglichen Probleme hinzufügen, die entstehen, wenn eine oder mehrere Anwendungsinstanzen bei einer langsamen oder fehlerhaften Internetverbindung oder schlimmer noch, wenn eine Instanz offline ist, verwendet werden. Es kann sich um stunden- oder tagelange Änderungen handeln, die überschrieben werden müssen oder überschrieben werden, wenn die Synchronisierung schließlich stattfindet. Wir sprechen selten von Millisekunden, sondern oft von Daten aus mehreren Tagen.

Wie dieses Problem – falls überhaupt – bei lokal gemeinsam genutzten Dateien gehandhabt wird, ist vielschichtig. Erstens gibt es nur eine Datei und keine Kopien dieser Datei. Somit stehen alle Änderungen allen Kopien der Anwendung gleichzeitig und unverzüglich zur Verfügung. Wenn eine Instanz der Anwendung Daten in die Datei schreiben möchte, verwendet sie einen Sperr- und Benachrichtigungsmechanismus, ähnlich der Funktionsweise von Clustered File Systems, die den Betrieb von SANs ermöglichen, wobei sie anderen Anwendungsinstanzen signalisieren kann, dass eine Änderung vorgenommen wird und dass diese warten müssen, bis sie abgeschlossen ist, und dann ihre Kopie der Daten aktualisieren müssen, bevor sie fortfahren. Nur eine Instanz kann schreiben, und alle anderen müssen warten. Es gibt keine Race Conditions, da die Sperre vor Beginn erlangt und nach Abschluss freigegeben wird. Und alle Instanzen funktionieren nur, solange aktuell auf die Daten zugegriffen werden kann; geht die Verbindung verloren, können sie nicht fortfahren. Ein entscheidender Mechanismus zum Schutz der Datenintegrität. Einige Anwendungen treiben diesen Mechanismus auf eine noch höhere Ebene und fügen direkte Kommunikationskanäle (anstatt über die gemeinsam genutzte Datei) hinzu, um diesen Prozess für eine bessere Leistung zu beschleunigen. Nur wenige gehen jedoch so weit, denn sobald man dieses Niveau erreicht, ist es im Allgemeinen weitaus einfacher, einfach auf eine moderne Anwendung umzusteigen, als zu versuchen, moderne Mehrbenutzersysteme in jahrzehntealte Designs hineinzuzwängen.

Hoffentlich hat dies geklärt, warum Buchhalter häufig glauben, dass synchronisierte Dateien funktionieren, und warum sie oft behaupten, es habe „bei mir funktioniert“, obwohl sie sagen sollten „ich hatte Glück“ oder „ich habe es in einem völlig anderen Szenario verwendet, das auf eine Mehrbenutzerumgebung nicht zutrifft“, und warum man Google Drive, NextCloud, iCloud, DropBox und mehr durchaus mit QuickBooks und anderen Anwendungen im Legacy-Stil für Sicherungen und Datenübertragungen verwenden kann, aber nicht in Betracht ziehen darf, sie als Mittel für den Mehrbenutzerzugriff zu nutzen, da sie die Daten schlichtweg nicht intakt halten können.