Varför QuickBooks inte kan lagras på Google Drive för flera användare

Innan vi går in på detaljer är det viktigt att förstå att detta är ett generellt koncept som vi faktiskt kan koka ner till “varför kan inte klient/server- eller delade databasfilbaserade applikationer lagras på synkroniserad lagring (t.ex. Google Drive, DropBox, NextCloud osv.) när åtkomsten inte är begränsad till en enda användare?” QuickBooks använder en mekanism med delade databasfiler som är vanlig i applikationer av 1980-talsmodell, där en enskild fil eller uppsättning filer delas via en fildelningsmekanism och enskilda applikationskopior var och en kommer åt denna fil för att ändra den. Google Drive är en synkroniserad lagringsmekanism: vilket innebär att den skapar kopior av data från en plats till en annan. Personer som arbetar med samma fil samtidigt kan, och gör det ofta, skriva över varandras ändringar, och förväntningen är att dessa ändringar ska stämmas av manuellt senare, ignoreras, eller att användarna ska styras så att de inte arbetar samtidigt.

För vissa typer av fleranvändarapplikationer kan synkroniserad lagring utnyttjas, men endast i situationer där applikationen kan låsas av lagringssystemet så att den endast tillåter ändringar när inga andra finns. Detta kräver en integrationsnivå som inte är praktisk med generell filsynkronisering. De flesta system som gör detta använder en synkroniseringsmekanism inbyggd antingen i databas- eller applikationslagret, inte en generell sådan som måste fungera i blindo. För att dataintegriteten ska kunna bevaras med synkroniserad lagring är det nödvändigt att endast en person redigerar en fil i taget, väntar på att alla potentiella användare ska ta emot ändringar som gjorts efter att filen “sparats”, och sedan kan en annan användare redigera filen och upprepa processen. Men endast en användare i taget kan arbeta med filen och måste ta emot den andra användarens uppdateringar innan han eller hon själv öppnar filen för redigering. Annars måste systemet i varje enskilt fall fråga användarna vilka ändringar som ska behållas och vilka som ska kasseras.

Denna integritetsprocess kan inte tillämpas på en databasfil på något realistiskt sätt. Filen är utformad för att vara öppen och åtkomlig hela tiden, inte bara för att snabbt öppnas, redigeras och sparas. Sparandet är inte heller manuellt och inte alltid förutsägbart. Vi antar i allmänhet att sparandet sker kontinuerligt under användningen, men cachning kan göra det omöjligt att manuellt styra även dessa sparoperationer. Men detta är nödvändigt av prestandaskäl.

Förvirring uppstår ofta eftersom en enskild användare, utan rädsla för att en annan användare kommer åt systemet samtidigt, kan använda synkroniserad lagring, som Google Drive eller Apple iCloud, för att fungera som en säkerhetskopieringsmekanism (den skapar helt enkelt en avlägsen kopia automatiskt) och/eller som ett sätt att replikera filen så att den enskilda användaren kan använda den först från en plats och sedan från en annan utan att behöva flytta filen manuellt mellan platserna. Så länge den enskilda användaren tar tillräckligt med tid på sig vid förflyttning mellan platser för att säkerställa att eventuell cache har tömts och att synkroniseringar och lås har slutförts, eller säkerställer att de inte har lämnat den första instansen av applikationen öppen, kan de rimligen anta ett säkert system (men kan inte helt garantera det – mekanismen medför även då en minimal risk för kapplöpningstillstånd.) Eftersom det finns “ett sätt” att säkert använda synkroniserad lagring med applikationen i enanvändarläge, antar många icke-tekniska redovisnings- eller ekonomimedarbetare felaktigt att samtidig fleranvändaråtkomst, som är något helt annat, också fungerar. Detta är dock inte möjligt.

Vad som händer är att du får ett kapplöpningstillstånd mellan flera användare och du kan aldrig vara helt säker på att det inte har inträffat. Ibland blir data helt enkelt felaktig och det råder ingen tvekan om att ett kapplöpningstillstånd har inträffat eftersom siffrorna blir vilt felaktiga. Men oftare går vissa transaktioner helt enkelt förlorade även efter att de har granskats.

Låt oss ta ett exempel. Användare 1 är hemma och matar in ett nytt kvitto i QuickBooks. Denna ändring börjar sparas på den lokala datorn, och efter att det har slutförts börjar den vidarebefordra den nya filen till Google Drive i molnet (online). Användare 2 är på kontoret och börjar under tiden mata in en kundbetalning på en faktura. Användare 2:s kopia av QuickBooks-datafilen är öppen och kan inte skrivas över medan den används, så kopian som skickas till Google Drive kan inte nå Användare 2. När Användare 2 sparar sin ändring vill även hans kopia skickas till Google Drive. Google Drive måste nu göra något åt två dokument som började likadant men nu har två radikalt olika ändringar i sig, men ingen av kopiorna har båda. Den har ingen möjlighet att slå samman dem, så den kan antingen acceptera Användare 1 som master och kassera ändringarna från Användare 2 (t.ex. förstaprioritet). Eller så kan den acceptera Användare 2:s ändringar och kassera Användare 1:s ändringar (t.ex. senaste prioritet). Eller så kan den förstås kassera alla ändringar och inte acceptera någon. I inget fall behålls alla användares finansiella transaktioner, inte ens efter att de har sparats lokalt. Antingen kommer Användare 1 eller Användare 2 (eller möjligen båda) att få data som de trodde hade sparats att plötsligt försvinna. Lägg till fler användare, så blir problemet bara större.

En del av problemet är att när man arbetar på filåtkomstnivå och synkroniserar och delar data på hela filnivå, finns det inget sätt att låsa endast en enda post eller rad, eller att hålla transaktioner åtskilda eller att slå samman ändringar. Filen är en enda enhet och den har ändrats. Det är allt eller inget. De enskilda QuickBooks-applikationerna kan inte kommunicera direkt med varandra, eller via databasfilen, för att samordna skrivningar, sparanden, läsningar osv. för att kringgå detta problem. De är blinda och kan inte veta att andra applikationer försöker arbeta med filen samtidigt, eftersom var och en har sin egen unika kopia av filen, det finns inget “delat” mellan dem som möjliggör kommunikation. Kopiorna är inte knutna till varandra, det är inget kvanttillstånd inblandat här. Och sedan kan vi lägga till de potentiella problemen med att en eller flera applikationsinstanser används när det finns en långsam eller buggig internetanslutning, eller ännu värre, när en instans är offline. Det kan finnas timmar eller dagar av ändringar som måste skriva över, eller skrivas över, när synkroniseringen äntligen sker. Vi talar sällan om millisekunder, utan ofta om dagars data.

Hur detta problem hanteras, när det hanteras, av lokalt delade filer är mångfacetterat. För det första finns det bara en fil, inte kopior av den filen. Så alla ändringar är tillgängliga för alla kopior av applikationen samtidigt och omedelbart. När en instans av applikationen ska skriva data till filen använder den en lås- och varningsmekanism liknande hur klustrade filsystem gör det möjligt för SAN-lösningar att fungera, där den kan signalera till andra applikationsinstanser att en ändring görs och att de måste vänta på att den slutförs, och sedan uppdatera sin kopia av data innan de fortsätter. Endast en instans kan skriva och alla andra måste vänta. Det finns inga kapplöpningstillstånd eftersom låset erhålls innan man börjar och frigörs när man är klar. Och alla instanser fungerar endast så länge data för närvarande är åtkomlig; om anslutningen förloras kan de inte fortsätta. En kritisk mekanism för skydd av dataintegritet. Vissa applikationer tar denna mekanism till en ännu högre nivå och lägger till direkta kommunikationskanaler (snarare än via den delade filen) för att göra denna process snabbare och ge bättre prestanda. Men få går så här långt, för när man väl når den nivån är det i allmänhet betydligt enklare att helt enkelt övergå till en modern applikation snarare än att försöka pressa in moderna fleranvändarsystem på decennier gamla konstruktioner.

Förhoppningsvis har detta klargjort varför revisorer ofta tror att synkroniserade filer kommer att fungera, och varför de ofta hävdar att det “fungerade för mig” när de borde säga “jag hade tur” eller “jag använde det i ett helt annat scenario som inte gäller fleranvändarmiljöer”, och varför du absolut kan använda Google Drive, NextCloud, iCloud, DropBox med flera tillsammans med QuickBooks och andra applikationer av äldre modell för säkerhetskopiering och dataöverföring, men inte kan överväga att försöka använda det som ett sätt att uppnå fleranvändaråtkomst, eftersom det helt enkelt inte kan hålla data intakt.