Hvorfor QuickBooks ikke kan lagres på Google Drive for flere brukere

Før vi går inn på detaljene, er det viktig å forstå at dette er et generelt konsept, og vi kan egentlig destillere det til “hvorfor kan ikke klient/server- eller delte databasefilapplikasjoner lagres på synkronisert lagring (f.eks. Google Drive, DropBox, NextCloud, osv.) når tilgangen ikke er begrenset til én enkelt bruker?” QuickBooks bruker en delt databasefilmekanisme som er vanlig i 1980-tallsstil applikasjoner, der én enkelt fil eller et sett med filer deles via en fildelingsmekanisme og individuelle applikasjonskopier hver for seg får tilgang til denne filen for å endre den. Google Drive er en synkronisert lagringsmekanisme: det betyr at den lager kopier av data fra ett sted til et annet. Brukere som jobber med den samme filen samtidig kan, og gjør det ofte, overskrive hverandres endringer, og forventningen er at disse endringene vil bli manuelt avstemt senere, ignorert, eller at brukere vil bli kontrollert slik at de ikke jobber samtidig.

For noen typer flerbrukerapplikasjoner kan synkronisert lagring benyttes, men bare i situasjoner der applikasjonen kan låses av lagringssystemet slik at kun én bruker kan gjøre endringer om gangen. Dette krever et integrasjonsnivå som ikke er praktisk med generell filsynkronisering. De fleste systemer som gjør dette, bruker en synkroniseringsmekanisme som er innebygd i enten database- eller applikasjonslaget, ikke en generell mekanisme som må fungere blindt. For at dataintegriteten skal opprettholdes med synkronisert lagring, er det nødvendig at kun én person redigerer en fil om gangen, venter på at alle potensielle brukere mottar oppdateringene som er gjort etter at filen er “lagret”, og deretter kan en annen bruker redigere filen og gjenta prosessen. Men bare én bruker om gangen kan jobbe med filen og må motta den andre brukerens oppdateringer før de selv åpner filen for redigering. Ellers må systemet spørre brukerne hvilke endringer som skal beholdes og hvilke som skal forkastes i hvert enkelt tilfelle.

Denne integritetsprosessen kan ikke anvendes på en databasefil på noen realistisk måte. Filen er designet til å være åpen og tilgjengelig hele tiden, ikke bare til raskt å åpne, redigere og lagre. Lagring er heller ikke manuell, og ikke alltid forutsigbar. Vi antar generelt at lagring skjer kontinuerlig under bruk, men caching kan gjøre selv disse lagringsoperasjonene umulige å kontrollere manuelt. Men dette er nødvendig av ytelseshensyn.

Forvirring oppstår ofte fordi en enkelt bruker, uten frykt for at en annen bruker får tilgang til systemet samtidig, kan bruke synkronisert lagring, som Google Drive eller Apple iCloud, som en sikkerhetskopieringsmekanisme (den lager bare automatisk en fjern kopi) og/eller som et middel til å replikere filen slik at den ene brukeren kan bruke den fra ett sted og deretter fra et annet uten å måtte flytte filen manuelt fra sted til sted. Så lenge den ene brukeren tar nok tid mellom steder til å sikre at all cache er tømt og at synkroniseringer og låser er fullførte, eller sørger for at de ikke har latt den første instansen av applikasjonen stå åpen, kan de med rimelighet anta et trygt system (men kan ikke garantere det fullstendig – mekanismen bærer en liten risiko for race conditions selv da). Fordi det “finnes en måte” å trygt bruke synkronisert lagring med applikasjonen i enkeltbrukermodus, vil mange ikke-tekniske regnskaps- eller finansarbeidere feilaktig anta at flerbruker samtidig tilgang, som er helt annerledes, også vil fungere. Dette er imidlertid ikke mulig.

Det som skjer er at du får en race condition mellom flere brukere, og du kan aldri være helt sikker på at det ikke har skjedd. Noen ganger vil data rett og slett være feil og det er ikke tvil om at en race condition har skjedd, ettersom tallene vil være vilt unøyaktige. Men oftere vil noen transaksjoner rett og slett gå tapt selv etter at de er blitt gjennomgått.

La oss gi et eksempel. Bruker 1 er hjemme og legger inn en ny kvittering i QuickBooks. Denne endringen begynner å lagres til den lokale datamaskinen, og etter at det er fullført, begynner den å videresende den nye filen til Google Drive i skyen (online). Bruker 2 er på kontoret og begynner å legge inn en kundebetaling på en faktura i løpet av denne tiden. Bruker 2 sin kopi av QuickBooks-datafilen er åpen og kan ikke overskrives mens den er i bruk, så kopien som sendes til Google Drive kan ikke nå Bruker 2. Når Bruker 2 lagrer sin endring, vil hans kopi også sende til Google Drive. Google Drive må nå gjøre noe med to dokumenter som startet identisk men nå har to radikalt forskjellige endringer i seg, men ingen av kopiene har begge. Det har ingen mulig måte å slå dem sammen, så det kan enten akseptere Bruker 1 som master og forkaste endringene fra Bruker 2 (f.eks. første prioritet). Eller det kan akseptere Bruker 2 sine endringer og forkaste Bruker 1 sine endringer (f.eks. siste prioritet). Eller, selvfølgelig, kan det forkaste alle endringer og akseptere ingen. I intet tilfelle blir alle brukernes finansielle transaksjoner beholdt selv etter at de har lagret dem lokalt. Enten Bruker 1 eller Bruker 2 (eller muligens begge) kommer til å ha data som de trodde var lagret som plutselig forsvinner for dem. Legg til flere brukere, og problemet bare vokser.

En del av problemet er at når man jobber på filaksessnivå, og synkroniserer og deler data på et fullstendig filnivå, er det ingen måte å låse bare én post eller rad, eller holde transaksjoner separate eller slå sammen endringer. Filen er en enkelt enhet og den har endret seg. Det er alt eller ingenting. De individuelle QuickBook-applikasjonene kan ikke kommunisere direkte med hverandre, heller ikke gjennom databasefilen, for å koordinere skriving, lagring, lesing osv. for å omgå dette problemet. De er blinde og kan ikke vite at andre applikasjoner forsøker å jobbe med filen samtidig fordi hver har sin egen unike kopi av filen, det er ingenting “delt” mellom dem som muliggjør kommunikasjon. Kopiene er ikke knyttet til hverandre, det er ingen kvantetilstand involvert her. Og så kan vi legge til de potensielle problemene med en eller flere applikasjonsinstanser som brukes når det er en treg eller feilbeheftet Internett-tilkobling, eller verre, når en instans er offline. Det kan være timer eller dager med endringer som må overskrive, eller overskrives av, andre endringer når synkroniseringen til slutt skjer. Vi snakker sjelden om millisekunder, men ofte om dagers data.

Hvordan dette problemet håndteres, når det håndteres, av lokalt delte filer er flerfasettert. For det første er det bare én fil, ikke kopier av den filen. Så alle endringer er tilgjengelige for alle kopier av applikasjonen simultant og umiddelbart. Når én instans av applikasjonen skal skrive data til filen, bruker den en låse- og varslingsmekanisme som ligner på hvordan Clustered File Systems lar SAN-er fungere, der den kan signalisere andre applikasjonsinstanser at en endring gjøres og at de må vente på at den fullføres, og deretter oppdatere sin kopi av dataene før de fortsetter. Bare én instans kan skrive og alle andre må vente. Det er ingen race conditions fordi låsen tas før arbeidet begynner og frigis når det er gjort. Og alle instanser fungerer bare så lenge dataene er tilgjengelige; hvis tilkoblingen mistes, kan de ikke fortsette. En kritisk mekanisme for beskyttelse av dataintegritet. Noen applikasjoner vil ta denne mekanismen til et enda høyere nivå og legge til direkte (i stedet for gjennom den delte filen) kommunikasjonskanaler for å gjøre denne prosessen raskere for bedre ytelse. Men få vil gå så langt, ettersom når du først er på det nivået, er det generelt mye enklere å bare flytte til en moderne applikasjon fremfor å forsøke å tvinge moderne flerbrukersystemer inn i tiår gamle design.

Forhåpentligvis har dette klargjort hvorfor regnskapsførere ofte kan tenke at synkroniserte filer vil fungere, og hvorfor de ofte vil påstå at det “fungerte for meg” når de egentlig burde si “jeg hadde flaks” eller “jeg brukte det i et helt annet scenario som ikke gjelder for flerbrukermiljø” – og hvorfor du absolutt kan bruke Google Drive, NextCloud, iCloud, DropBox og mer med QuickBooks og andre eldre applikasjoner for sikkerhetskopier og dataoverføringer, men ikke kan forsøke å bruke det som et middel for å oppnå flerbrukertilgang ettersom det rett og slett ikke kan holde dataene intakte.