Hvorfor QuickBooks ikke kan gemmes på Google Drive til flere brugere

Inden vi går i detaljer, er det vigtigt at forstå, at dette er et generelt koncept, som vi faktisk kan destillere til “hvorfor kan klient/server- eller delte databasefilapplikationer ikke gemmes på synkroniseret lager (f.eks. Google Drive, DropBox, NextCloud osv.), når adgangen ikke er kontrolleret til en enkelt bruger?” QuickBooks bruger en delt databasefilmekanisme, der er typisk for 1980'ernes applikationer, hvor en enkelt fil eller et sæt filer deles via en fildelingsmekanisme, og individuelle applikationskopier hver tilgår denne fil for at ændre den. Google Drive er en synkroniseret lagringsmekanisme: det vil sige, at den laver kopier af data fra ét sted til et andet. Brugere, der arbejder på den samme fil på samme tid, kan og gør ofte hinandens ændringer ugyldige, og forventningen er, at disse ændringer vil blive manuelt afstemt senere, ignoreret, eller at brugerne vil blive kontrolleret for at forhindre dem i at arbejde på samme tid.

For nogle typer flerbrugerapplikationer kan synkroniseret lager udnyttes, men kun i situationer, hvor applikationen er i stand til at blive låst af lagersystemet til kun at tillade ændringer, når ingen andre eksisterer. Dette kræver et integrationsniveau, der ikke er praktisk med generel filsynkronisering. De fleste systemer, der gør dette, bruger en synkroniseringsmekanisme, der er indbygget i enten database- eller applikationslaget, ikke en generel, der blindt skal fungere. For at dataintegriteten kan opretholdes med synkroniseret lager, er det nødvendigt, at kun én person redigerer en fil ad gangen, venter på, at alle potentielle brugere modtager opdateringer foretaget efter “gem” af den pågældende fil, og derefter kan en anden bruger redigere den fil og gentage processen. Men kun én bruger ad gangen kan arbejde på filen og skal modtage den anden brugers opdateringer, inden de åbner filen til redigering selv. Ellers skal systemet bede brugerne om, hvilke ændringer der skal beholdes, og hvilke der skal kasseres i hvert enkelt tilfælde.

Denne integrationsproces kan ikke på nogen realistisk måde anvendes på en databasefil. Filen er designet til at være åben og tilgået hele tiden, ikke blot til hurtigt at åbne, redigere og gemme. Lagring er heller ikke manuel og altid forudsigelig. Vi antager generelt, at lagring sker løbende under brug, men caching kan gøre selv disse lagringshændelser umulige at manuelt styre. Men dette er nødvendigt af præstationsmæssige årsager.

Forvirring opstår ofte, fordi en enkelt bruger uden frygten for, at en anden bruger tilgår systemet på samme tid, kan bruge synkroniseret lager, såsom Google Drive eller Apple iCloud, som en sikkerhedskopieringsmekanisme (den laver simpelthen automatisk en fjernkopi) og/eller som et middel til at replikere filen, så den enkelte bruger kan bruge den først fra ét sted, derefter fra et andet uden at skulle flytte filen manuelt fra sted til sted. Så længe denne enkeltbruger tager tilstrækkelig tid til at flytte mellem steder for at sikre, at eventuel cache er tømt, og at synkroniseringer og låse er fuldført, eller sikrer, at de ikke har efterladt den første instans af applikationen åben, kan de med rimelighed antage et sikkert system (men kan ikke fuldt ud garantere det – mekanismen indebærer minimal risiko for race conditions selv da). Fordi der “er en måde” at bruge synkroniseret lager sikkert med applikationen i enkeltbrugertilstand, vil mange ikke-tekniske regnskabs- eller økonomimedarbejdere fejlagtigt antage, at flerbruger-samtidsadgang, som er helt anderledes, også vil fungere. Dette er imidlertid ikke muligt.

Det, der sker, er, at der opstår en race condition mellem flere brugere, og man kan aldrig være helt sikker på, at det ikke er sket. Nogle gange vil data simpelthen være forkerte, og der er ingen tvivl om, at en race condition er opstået, da tal vil være voldsomt unøjagtige. Men oftere vil nogle transaktioner simpelthen gå tabt selv efter at de er blevet gennemgået.

Lad os give et eksempel. Bruger 1 er hjemme og indtaster en ny kvittering i QuickBooks. Denne ændring begynder at gemme på den lokale computer, og når det er fuldført, begynder den at videresende den nye fil til Google Drive i skyen (online). Bruger 2 er på kontoret og begynder at indtaste en kundebetaling på en faktura i løbet af denne tid. Bruger 2's kopi af QuickBooks-datafilen er åben og kan ikke overskrives, mens den er i brug, så kopien, der sendes til Google Drive, kan ikke nå Bruger 2. Når Bruger 2 gemmer sin ændring, ønsker hans kopi også at sende til Google Drive. Google Drive skal nu gøre noget med to dokumenter, der startede ens, men nu har to radikalt forskellige ændringer til dem, men ingen kopi har begge. Der er ingen mulig måde at flette dem på, så den kan enten acceptere Bruger 1 som master og kassere ændringerne fra Bruger 2 (f.eks. første prioritet). Eller den kan acceptere Bruger 2's ændringer og kassere Bruger 1's ændringer (f.eks. seneste prioritet). Eller den kan selvfølgelig kassere alle ændringer og acceptere ingen. I intet tilfælde bevares alle brugeres finansielle transaktioner, selv efter at de har gemt dem lokalt. Enten Bruger 1 eller Bruger 2 (eller muligvis begge) vil have data, som de troede var gemt, der pludselig forsvinder for dem. Tilføj flere brugere, og problemet bliver bare større.

En del af problemet er, at når man arbejder på et filadgangsniveau og synkroniserer og deler data på et fuldt filniveau, er der ingen måde at låse kun én post eller række, eller at holde transaktioner adskilt eller flette ændringer. Filen er en enkelt enhed, og den er ændret. Det er alt eller intet. De individuelle QuickBooks-applikationer kan ikke tale direkte med hinanden, heller ikke via databasefilen, for at koordinere skrivninger, gemninger, læsninger osv. for at løse dette problem. De er blinde og kan ikke vide, at andre applikationer forsøger at arbejde med filen på samme tid, fordi hver har sin egen unikke kopi af filen, der er intet “delt” mellem dem til at muliggøre kommunikation. Kopierne er ikke bundet til hinanden, der er ingen kvantetilstand involveret her. Og så kan vi tilføje de potentielle problemer med en eller flere applikationsinstanser, der bruges, når der er en langsom eller fejlbehæftet internetforbindelse, eller værre, når en instans er offline. Der kan være timer eller dages ændringer, der skal overskrive eller overskrives, når synkronisering endelig sker. Vi taler sjældent om millisekunder, men ofte dages data.

Hvordan dette problem håndteres, når det håndteres, af lokalt delte filer er mangesidet. For det første er der kun én fil, ikke kopier af den fil. Så alle ændringer er tilgængelige for alle kopier af applikationen simultant og øjeblikkeligt. Når én instans af applikationen skal skrive data til filen, bruger den en låse- og advarselsmekanisme svarende til, hvordan Clustered File Systems giver SAN'er mulighed for at fungere, hvor den kan signalere andre applikationsinstanser, at en ændring foretages, og at de skal vente på, at den er fuldført, og derefter opdatere deres kopi af dataene, inden de fortsætter. Kun én instans kan skrive, og alle andre skal vente. Der er ingen race conditions, fordi låsen opnås, inden man begynder, og frigives, når man er færdig. Og alle instanser fungerer kun, så længe dataene er tilgængelige i øjeblikket; hvis forbindelsen mistes, kan de ikke fortsætte. En kritisk databeskyttelsesmekanisme. Nogle applikationer vil tage denne mekanisme til et endnu højere niveau og tilføje direkte (snarere end via den delte fil) kommunikationskanaler for at gøre denne proces hurtigere og opnå bedre ydeevne. Men få vil gå så langt, da det generelt er meget lettere blot at flytte til en moderne applikation end at forsøge at tilpasse moderne flerbrugersystemer til årtier gamle designs.

Forhåbentlig har dette afklaret, hvorfor revisorer ofte kan tro, at synkroniserede filer vil fungere, og hvorfor de ofte vil hævde, at det “virkede for mig”, når de burde sige “jeg var heldig” eller “jeg brugte det i et helt andet scenarie, der ikke gælder for flerbrugermiljøer”, og hvorfor du absolut kan bruge Google Drive, NextCloud, iCloud, DropBox og mere med QuickBooks og andre ældre stil applikationer til sikkerhedskopiering og dataoverførsler, men ikke kan betragte det som et middel til at opnå flerbrugeradgang, da det simpelthen ikke kan holde dataene intakte.