Two People Updating the Same Spreadsheet: How to Stop Silent Overwrites

A silent overwrite occurs when two people load the same row, both edit it, and the second save replaces the first without anyone being told. Google Sheets merges edits at cell level. An Excel file on a network share does not merge at all. The control you need follows from where the file lives.

A silent overwrite, minute by minute

Dana handles orders, Amir handles stock. Both work in the same orders spreadsheet. Neither of them did anything wrong.

Dana's change disappeared at 09:23. No error appeared, nobody was asked anything, and the discovery arrives with the customer return. That is a silent overwrite: not a bug and not carelessness, but the default behaviour of a tool with no update control.

Why does Google Sheets survive this and an Excel file on a share does not?

Because they operate on a different unit. Google Sheets transmits each edit separately and merges it at cell level, so two people editing different cells in the same row do not overwrite each other. Excel on a traditional network share works at file level: whoever opened first holds the lock, and the second person gets read-only or saves a copy.

Microsoft documents the conditions explicitly. Co-authoring requires the file to be stored on OneDrive, OneDrive for Business or SharePoint, and is not supported on server paths of the form \\server\folder or on third-party cloud drives. Two further traps break it even when the file is in the right place:

• One user opens it in an Office version that does not support co-authoring, and everyone else receives the locked message.
• The file contains a PivotTable or data connection with "Refresh data when opening the file" ticked. That option disables co-authoring.

Where the file lives decides which failure you get

The last row is the only one where the conflict becomes a visible event. In all the others it is resolved in the background, sometimes at someone's expense.

The Access answer: the Write Conflict dialog

When an Access application is split into front end and back end, locking is at record level, and a user saving a record that changed in the meantime gets a Write Conflict dialog with three options:

• Save Record - overwrites the other person's change. Whoever held the lock wins, and the other loses their work.
• Copy to Clipboard - copies the record with your changes to the clipboard and displays the other person's changes, so you can compare and decide.
• Drop Changes - you give up your edit and let theirs stand.

The middle button is the only one that preserves both versions, and it is the one almost nobody presses. One confusing case Microsoft documents is worth knowing: the dialog also appears when a single user has the same record open in a form and in a table at once. "The other person" is then you.

What "last write wins" costs, and how to stop it

Two approaches work, and they are not mutually exclusive:

1. Optimistic concurrency on a version field. Each row carries a field that changes on every update. The client sends back the value it read; if that no longer matches, the save is rejected. In SQL Server this is the rowversion type, and Access uses it in a linked table to determine when the record was last updated.
2. Ownership of a field, not of a row. Dana owns quantity, Amir owns status. If each writes only to their own fields, the conflict simply does not exist. This is the cheapest approach and almost always the right one for an operational spreadsheet.

The third approach, pessimistic locking - reserving the row for exclusive editing - is correct for short transactions and harmful the moment someone walks into a meeting with a row still locked.

Which questions do you answer before picking a mechanism?

• How long passes between a row being loaded and being saved? Five seconds and two minutes are different problems.
• Are the two people touching the same field, or only the same row?
• What does it cost to reconstruct an overwrite discovered two days later? That sets how much control is justified.
• Do you need a record of who changed what? Google Sheets offers right-click on a cell > Show edit history, plus version history for the file.
• Who decides when both versions are legitimate?

Controls you can add to a spreadsheet this week

• Move the file to OneDrive or SharePoint if it sits on a network share, so real co-authoring becomes possible.
• Set protected ranges so each role writes only to its own columns.
• Add "updated by" and "updated at" columns written automatically.
• Untick "Refresh data when opening the file" on every PivotTable and data connection in the workbook.
• Separate input from reports, so two people are not writing into the same tab to begin with.
• Write down one clear rule about who updates which field - in the sheet itself, not in somebody's memory.

When the collisions come from the database rather than from the spreadsheet, the symptoms differ - see diagnosing SQL deadlocks and timeouts. And if the spreadsheet itself has become infrastructure, read when a spreadsheet has outgrown itself and handing over a single-owner spreadsheet.

Sources

• Collaborate on Excel workbooks at the same time with co-authoring - Microsoft Support
• Write Conflict dialog box - Microsoft Support
• Find what's changed in a file - Google Docs Editors Help