SyteLine 'row has been modified by another user': what it means and how to stop it

Why SyteLine does this

This is called optimistic concurrency. SyteLine doesn't lock a record while you look at it, because that would block everyone else. Instead it checks at save time whether the record still matches what you loaded. Most of the time it does. When it doesn't, refusing the save is the right behavior: the alternative is silently throwing away the other change.

So the error itself isn't the bug. The thing that changed the record is what you investigate.

The usual triggers

1. Two people editing the same record. Common on shared records like customer orders being changed by sales and shipping at the same time.
2. A form left open for a long time. A user opens an order in the morning, a background task updates it at lunch, and the user saves in the afternoon.
3. Background tasks. Utilities, posting runs and scheduled processes update records while users have them open.
4. Integrations. EDI, e-commerce, warehouse and other systems write to the same records users edit.
5. Direct SQL updates. Any script that writes to SyteLine tables changes the record's version without users knowing. It also bypasses SyteLine's business logic, which is a bigger problem. See the rules in the SQL table cheat sheet.
6. Custom code that saves the same record twice in one action, or updates a related record that the form then tries to save again.

Fixing it for the user, right now

1. Note the change you were making.
2. Refresh the form, or close and reopen the record. Unsaved edits are lost.
3. Look at what changed. It may affect your edit.
4. Re-apply the change and save.

Fixing it for good

If the same records or the same form keep hitting the error:

• Look at the timing. If it happens at the same time each day, compare it with the background task schedule in Active Background Tasks and Background Task History.
• Look at who updated it. Most SyteLine tables carry UpdatedBy and RecordDate audit columns. Checking them on an affected record, on a test copy or with read-only access, often names the process or user that changed it.
• Check integrations that write to that table, and when they run.
• Check for direct SQL jobs, such as SQL Agent jobs or scripts someone set up years ago to "fix" data.
• Review custom form events on that form for actions that save twice.
• Check for bulk changes. Someone running a mass update (for example, Replace Value in Collection across hundreds of records) while others are editing the same records will trigger this error for them. Do bulk changes at quiet times. See Mass update records in SyteLine without SQL.

Then fix the cause: reschedule the task outside working hours, change the integration to update fewer fields or less often, retire the SQL job in favor of a proper utility, or correct the custom event.

What not to do

• Don't look for a way to bypass the check, for example by writing the change with SQL instead. It's what stops lost updates, and SQL also skips SyteLine's business logic.
• Don't train users to just retry. If they re-save without refreshing, they're working from old data.
• Don't increase timeouts. This isn't a timeout. It's two writes colliding.

FAQ

What does "row has been modified by another user" mean in SyteLine?

Someone or something changed the record after you opened it, so SyteLine refused your save to avoid overwriting their change.

How do I fix "row has been modified by another user"?

Refresh the form, re-apply your change and save. If it repeats, find the user, task or integration that keeps updating the record.

Can a background task cause this error?

Yes. Utilities, posting runs and scheduled processes often update records users have open.

Can I stop SyteLine checking for changes by other users?

You shouldn't try. The check prevents silent lost updates. Find and fix whatever is changing the records instead.