# SyteLine error: this row has been modified by another user since you began editing it

> Source: https://netray.co/erp-help/syteline-row-modified-by-another-user-error
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

This is SyteLine's IDO optimistic concurrency check. It fires when the row's timestamp column (usually ts_prefix or a similar rowversion field) on the database no longer matches the value the client loaded, meaning another session, a background job, or an integration already saved a change. Refresh the record and reapply your edit; if it recurs constantly on one record, look for a duplicate integration process or a stuck lock rather than user contention.

## Kind

error

## System

syteline

## Erp

Infor SyteLine (CloudSuite Industrial)

## Module

IDO Data Layer / Forms

## Query

This row has been modified by another user since you began editing it

## Alternate Queries

- SyteLine row has been changed by another user error
- IDO optimistic concurrency error SyteLine
- SyteLine save fails row modified error

## Applies To

SyteLine 8.x, 9.x, CloudSuite Industrial (all supported versions using IDO-based forms)

## Steps

### Resolve the concurrency conflict

**Items:**

- Click OK/Cancel to dismiss the error, then refresh the form (F5 or the Refresh toolbar button) to reload the current row.
- Reapply your change on the refreshed data and save again.
- If it fails again immediately, check whether a scheduled task, workflow, or integration (ION, EDI import, custom IDO call) is also writing to that record.
- Open Task Manager / Scheduled Tasks in SyteLine and look for jobs touching the same table around the same timestamp.
- For a record that is permanently stuck, query the table directly for a lock: SELECT * FROM sysprocesses (SQL Server) or check for an open transaction holding the row.
- If a custom IDO extension class commits its own transaction outside the standard IDO save, review it - manual commits can update the timestamp column without the UI knowing.
- As a last resort on a genuinely orphaned edit, have an admin reopen the record fresh (no cached grid row) and re-enter the change.

## Sections

### Why the timestamp column exists

**Body:**

SyteLine IDOs implement optimistic concurrency rather than row locking. Every table that IDOs manage carries a timestamp or rowversion-style column that changes automatically on every UPDATE. When the client opens a record it caches that value; on save, the IDO layer issues an UPDATE with a WHERE clause that includes the original timestamp. If zero rows match, the framework knows someone else committed first and raises this error instead of silently overwriting their change.

This is by design and protects data integrity in a multi-user ERP. The error is annoying but it is doing its job: without it, two planners editing the same job order could each save a partial, conflicting version and neither would know.

### The three real-world causes

**Body:**

Two users editing the same record is the obvious cause and the easiest to diagnose: ask who else had that customer order, job, or item open. Less obvious is a long-running grid session - a user opens a list view in the morning, leaves it open for hours, and tries to edit a stale cached row in the afternoon after background processes (MRP, APS, EDI) have already touched it.

The third cause, and the one worth investigating if it happens repeatedly on the same table, is an integration or custom extension that updates rows outside the normal IDO save path, for example a direct SQL UPDATE from a nightly script or a poorly written IDO extension class that calls SetProperty and Save in a loop without refreshing between iterations.

### Diagnosing recurring conflicts

**Body:**

If this shows up sporadically across many tables and users, it is normal system behavior and training the team to refresh before editing is the fix. If it clusters on one table (commonly co_item, oe_ordl, or job_route rows during peak transaction windows), pull the SyteLine event log or SQL Profiler trace around the failure time and correlate with scheduled task history in Task Manager.

**Code:**

-- SQL Server: find blocking/long transactions that might be racing with UI saves
SELECT session_id, status, blocking_session_id, wait_type, wait_time, last_request_start_time
FROM sys.dm_exec_requests
WHERE database_id = DB_ID('YourSyteLineDB')
ORDER BY last_request_start_time DESC;

## Pitfalls

- Do not disable or work around IDO concurrency checking in a custom extension class just to make the error go away - you will silently lose updates.
- Do not assume it is always a two-user collision; check scheduled tasks and integrations first if it recurs on the same table.
- Leaving grid views or forms open for hours is the single biggest cause of stale-cache conflicts - encourage users to close forms they are not actively using.
- Custom code that commits SQL updates directly against IDO-managed tables (bypassing the IDO Save method) will cause this error for every user with that record open, and is a maintenance trap.
- Retrying the same save without refreshing first will fail again with the same error - you must reload the row.

## Ai Angle

ERPray can watch for repeated concurrency errors on the same table across sessions and flag the pattern - for example, if the same job route rows conflict every night at 2am, it can trace that back to a scheduled task or integration window instead of leaving each occurrence looking like random user contention, which cuts the diagnosis time from hours of log correlation to a single grounded query.

## Faq

### Does refreshing lose my unsaved changes?

**Answer:** Yes. Refreshing reloads the record from the database, which discards your unsaved edit. There is no merge; you need to reapply the change manually after refreshing, so it helps to note what you changed before clicking refresh.

### Is this the same as a database lock timeout?

**Answer:** No. A lock timeout means SQL Server could not even acquire access to the row within the timeout period, and produces a different error. This concurrency error means the UPDATE succeeded in reaching the row but found the timestamp already changed by a prior committed transaction.

### Can I increase a timeout to stop this from happening?

**Answer:** No timeout setting fixes this because it is not a timing issue, it is a genuine conflicting write. The fix is process (avoid long-open forms, coordinate concurrent edits) or fixing an integration that writes outside the IDO layer.

### Which tables see this most often?

**Answer:** In practice it clusters on high-traffic transactional tables touched by both users and background jobs: order lines, job operations, and inventory transaction headers, especially in shops running EDI or ION integrations alongside manual data entry.

## Search terms

syteline row modified by another user, syteline concurrency error, syteline this row has been changed by another user, IDO optimistic concurrency SyteLine, SyteLine save error timestamp, syteline ts_prefix error, csi row conflict error, syteline record locked another session

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json