Waarom QuickBooks niet op Google Drive kan worden opgeslagen voor meerdere gebruikers

Voordat we ingaan op de details, is het belangrijk om te begrijpen dat dit een algemeen concept is dat we eigenlijk kunnen herleiden tot “waarom kunnen client/server- of gedeelde-databasebestand-applicaties niet op gesynchroniseerde opslag (bijv. Google Drive, DropBox, NextCloud, enz.) worden opgeslagen wanneer de toegang niet tot één enkele gebruiker wordt beperkt?” QuickBooks gebruikt een mechanisme met een gedeeld databasebestand dat gangbaar is bij applicaties in de stijl van de jaren 1980, waarbij een enkel bestand of een set bestanden via een bestandsdelingsmechanisme wordt gedeeld en afzonderlijke kopieën van de applicatie elk toegang krijgen tot dit bestand om het te wijzigen. Google Drive is een mechanisme voor gesynchroniseerde opslag: dat betekent dat het kopieën van gegevens van de ene locatie naar de andere maakt. Mensen die tegelijkertijd aan hetzelfde bestand werken kunnen, en doen dit vaak, elkaars wijzigingen overschrijven, en de verwachting is dat deze wijzigingen later handmatig met elkaar in overeenstemming worden gebracht, genegeerd worden, of dat gebruikers worden beperkt zodat ze niet tegelijkertijd werken.

Voor sommige soorten applicaties met meerdere gebruikers kan gesynchroniseerde opslag worden benut, maar alleen in situaties waarin de applicatie door het opslagsysteem kan worden vergrendeld om alleen wijzigingen toe te staan wanneer er geen andere bestaan. Dit vereist een mate van integratie die niet praktisch is met algemeen bestandssynchronisatie. De meeste systemen die dit doen, gebruiken een synchronisatiemechanisme dat is ingebouwd in ofwel de databaselaag ofwel de applicatielaag, niet een algemeen mechanisme dat blind moet werken. Om de gegevensintegriteit met gesynchroniseerde opslag te behouden, is het noodzakelijk dat slechts één persoon tegelijk een bestand bewerkt, wacht totdat alle mogelijke gebruikers de updates hebben ontvangen die zijn gemaakt na het “opslaan” van dat bestand, en dat vervolgens een andere gebruiker dat bestand kan bewerken en het proces herhaalt. Maar slechts één gebruiker tegelijk kan aan het bestand werken en moet de updates van de andere gebruiker ontvangen voordat hij het bestand zelf ter bewerking opent. Anders moet het systeem in elk geval aan de gebruikers vragen welke wijzigingen behouden moeten blijven en welke verworpen moeten worden.

Dit integriteitsproces kan op geen enkele realistische manier worden toegepast op een databasebestand. Het bestand is ontworpen om voortdurend open te staan en benaderd te worden, niet alleen om snel te openen, te bewerken en op te slaan. Opslaan gebeurt ook niet handmatig en is niet altijd voorspelbaar. We gaan er over het algemeen van uit dat opslaan continu plaatsvindt tijdens het gebruik, maar caching kan zelfs die opslaghandelingen onmogelijk handmatig te beheersen maken. Maar dit is noodzakelijk om prestatieredenen.

Verwarring ontstaat vaak omdat een enkele gebruiker, zonder de angst dat een andere gebruiker het systeem tegelijkertijd benadert, gesynchroniseerde opslag zoals Google Drive of Apple iCloud kan gebruiken als back-upmechanisme (het maakt eenvoudigweg automatisch een kopie op afstand) en/of als een manier om het bestand te repliceren zodat de enkele gebruiker het eerst vanaf de ene locatie en daarna vanaf een andere kan gebruiken zonder het bestand handmatig van de ene naar de andere locatie te hoeven verplaatsen. Zolang die enkele gebruiker voldoende tijd neemt bij het wisselen tussen locaties om te zorgen dat eventuele cache is geleegd en dat synchronisaties en vergrendelingen zijn voltooid, of zorgt dat hij niet de eerste instantie van de applicatie open heeft gelaten, kan hij redelijkerwijs uitgaan van een veilig systeem (maar kan dit niet volledig garanderen – het mechanisme draagt zelfs dan een minuscuul risico op race-condities). Omdat er “een manier” is om gesynchroniseerde opslag veilig met de applicatie te gebruiken in een modus voor één gebruiker, zullen veel niet-technische boekhoud- of financiële medewerkers ten onrechte aannemen dat gelijktijdige toegang door meerdere gebruikers, wat iets compleet anders is, ook zal werken. Dit is echter niet mogelijk.

Wat er gebeurt, is dat je een race-conditie hebt tussen meerdere gebruikers en je kunt er nooit helemaal zeker van zijn dat deze zich niet heeft voorgedaan. Soms zijn de gegevens gewoon slecht en is er geen twijfel dat er een race-conditie is opgetreden, omdat de cijfers wild onnauwkeurig zullen zijn. Maar vaker zullen sommige transacties simpelweg verloren gaan zelfs nadat ze zijn gecontroleerd.

Laten we een voorbeeld geven. Gebruiker 1 is thuis en voert een nieuwe bon in QuickBooks in. Deze wijziging begint te worden opgeslagen op de lokale computer en nadat dat is voltooid, begint deze het nieuwe bestand door te sturen naar Google Drive in de cloud (online). Gebruiker 2 is op kantoor en begint in deze tijd een klantbetaling op een factuur in te voeren. De kopie van het QuickBooks-gegevensbestand van Gebruiker 2 is geopend en kan niet worden overschreven terwijl het in gebruik is, dus de kopie die naar Google Drive wordt verzonden kan Gebruiker 2 niet bereiken. Zodra Gebruiker 2 zijn wijziging opslaat, wil zijn kopie deze ook naar Google Drive verzenden. Google Drive moet nu iets doen met twee documenten die identiek begonnen maar nu twee radicaal verschillende wijzigingen bevatten, terwijl geen van beide kopieën beide wijzigingen bevat. Het heeft geen enkele manier om ze samen te voegen, dus het kan ofwel Gebruiker 1 als de master accepteren en de wijzigingen van Gebruiker 2 verwerpen (bijv. eerste prioriteit). Of het kan de wijzigingen van Gebruiker 2 accepteren en de wijzigingen van Gebruiker 1 verwerpen (bijv. laatste prioriteit). Of, uiteraard, het kan alle wijzigingen verwerpen en er geen accepteren. In geen enkel geval blijven de financiële transacties van alle gebruikers behouden, zelfs nadat ze ze lokaal hebben opgeslagen. Ofwel Gebruiker 1 ofwel Gebruiker 2 (of mogelijk beide) zullen gegevens hebben waarvan ze dachten dat die waren opgeslagen, die plotseling voor hun ogen verdwijnen. Voeg er meer gebruikers aan toe, en het probleem wordt alleen maar groter.

Een deel van het probleem is dat wanneer je op het niveau van bestandstoegang werkt en gegevens synchroniseert en deelt op het niveau van het volledige bestand, er geen manier is om slechts één record of rij te vergrendelen, of om transacties gescheiden te houden of wijzigingen samen te voegen. Het bestand is een enkele entiteit en het is gewijzigd. Het is alles of niets. De afzonderlijke QuickBooks-applicaties kunnen niet rechtstreeks met elkaar communiceren, noch via het databasebestand, om schrijfacties, opslagacties, leesacties enz. te coördineren om dit probleem te omzeilen. Ze zijn blind en kunnen niet weten dat andere applicaties tegelijkertijd met het bestand proberen te werken, omdat elke applicatie zijn eigen unieke kopie van het bestand heeft; er is niets “gedeelds” tussen hen dat communicatie mogelijk maakt. De kopieën zijn niet aan elkaar gekoppeld, er is hier geen sprake van een kwantumtoestand. En dan kunnen we de potentiële problemen toevoegen wanneer een of meer applicatie-instanties worden gebruikt bij een trage of buggy internetverbinding of, erger nog, wanneer een instantie offline is. Er kunnen uren of dagen aan wijzigingen zijn die moeten overschrijven, of overschreven moeten worden, wanneer de synchronisatie eindelijk plaatsvindt. We hebben het zelden over milliseconden, maar vaak over dagen aan gegevens.

Hoe dit probleem wordt aangepakt, wánneer het wordt aangepakt, door lokaal gedeelde bestanden is veelzijdig. Ten eerste is er slechts één bestand, geen kopieën van dat bestand. Dus alle wijzigingen zijn gelijktijdig en onmiddellijk beschikbaar voor alle kopieën van de applicatie. Wanneer één instantie van de applicatie gegevens naar het bestand gaat schrijven, gebruikt deze een vergrendelings- en waarschuwingsmechanisme dat lijkt op de manier waarop Clustered File Systems SAN's laten werken, waarbij het andere applicatie-instanties kan signaleren dat er een wijziging wordt gemaakt en dat ze moeten wachten totdat deze is voltooid, en vervolgens hun kopie van de gegevens moeten vernieuwen voordat ze verdergaan. Slechts één instantie kan schrijven en alle andere moeten wachten. Er zijn geen race-condities omdat de vergrendeling wordt verkregen voordat wordt begonnen en wordt vrijgegeven wanneer klaar. En alle instanties functioneren alleen zolang de gegevens momenteel toegankelijk zijn; als de verbinding verloren gaat, kunnen ze niet verdergaan. Een cruciaal beschermingsmechanisme voor de gegevensintegriteit. Sommige applicaties tillen dit mechanisme naar een nog hoger niveau en voegen directe communicatiekanalen toe (in plaats van via het gedeelde bestand) om dit proces sneller te maken voor betere prestaties. Maar weinig gaan zo ver, want zodra je naar dat niveau gaat, is het over het algemeen veel eenvoudiger om simpelweg over te stappen op een moderne applicatie dan te proberen moderne systemen voor meerdere gebruikers in tientallen jaren oude ontwerpen te wringen.

Hopelijk heeft dit verduidelijkt waarom boekhouders vaak denken dat gesynchroniseerde bestanden zullen werken en waarom ze vaak zullen beweren dat het “bij mij werkte” terwijl ze zouden moeten zeggen “ik had geluk” of “ik gebruikte het in een compleet ander scenario dat niet van toepassing is op een omgeving met meerdere gebruikers”, en waarom je Google Drive, NextCloud, iCloud, DropBox en meer absoluut kunt gebruiken met QuickBooks en andere applicaties in de oude stijl voor back-ups en gegevensoverdrachten, maar het niet kunt overwegen te gebruiken als middel om toegang voor meerdere gebruikers te verkrijgen, aangezien het de gegevens simpelweg niet intact kan houden.