The spreadsheet that lost a month of work

It is a Tuesday in a college office in Coimbatore. Two clerks, Priya and Arun, share one spreadsheet of student records on a network drive. It has worked for three years.

At 11:04 Priya opens it and corrects the address of student 41.

At 11:06 Arun opens it too. His copy is the version from before Priya started, because that is what was on disk when he clicked. He does not know this. There is nothing on his screen to tell him.

At 11:19 Priya saves. Student 41's new address is on the drive.

At 11:31 Arun saves. His copy overwrites the whole file, including student 41, whose address goes back to the old one.

Nobody sees an error. Nobody sees anything at all. In March a letter goes to the wrong house and the office spends a week working out why.

What actually went wrong

Not carelessness. Both clerks did exactly what they were asked to do. The file had no way to notice that two people were holding it at once, and no way to merge what each of them changed.

That single failure has a name, the lost update, and preventing it is one of the reasons databases exist. There are three more hiding in the same file:

The same fact, stored many times. Every student row carries the department head's name. Change the head and you must find all 300 rows. Miss one and the file now claims two different things are true at once.

Nothing checks anything. A slipped finger types CGPA 87 where 8.7 was meant. The spreadsheet accepts it happily, and so does the next one that reads it.

One permission: open. The accounts office needs fees. There is no way to show them fees without also showing them everyone's marks.

What a database does about it

Everything in the eleven pages after this one is a way of keeping one of those four promises.