SyteLine error: this row has been modified by another user since you began editing it
This row has been modified by another user since you began editing it
Also searched as
- SyteLine row has been changed by another user error
- IDO optimistic concurrency error SyteLine
- SyteLine save fails row modified error
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.
Applies to: SyteLine 8.x, 9.x, CloudSuite Industrial (all supported versions using IDO-based forms)
Resolve the concurrency conflict
- 1Click OK/Cancel to dismiss the error, then refresh the form (F5 or the Refresh toolbar button) to reload the current row.
- 2Reapply your change on the refreshed data and save again.
- 3If it fails again immediately, check whether a scheduled task, workflow, or integration (ION, EDI import, custom IDO call) is also writing to that record.
- 4Open Task Manager / Scheduled Tasks in SyteLine and look for jobs touching the same table around the same timestamp.
- 5For 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.
- 6If 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.
- 7As a last resort on a genuinely orphaned edit, have an admin reopen the record fresh (no cached grid row) and re-enter the change.
Why the timestamp column exists
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
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
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.
-- 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;Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
Does refreshing lose my unsaved changes?
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?
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?
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?
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.
Related
Fixing SyteLine's 'Object reference not set to an instance of an object' error
This is a generic .NET NullReferenceException surfacing through the SyteLine IDO Runtime, not a SyteLine-specific error code. It almost always means a form, script or IDO method referenced a field, row or object that came back null, usually after a customization, a missing related record, or a view/IDO method call before the form finished loading. Turn on detailed client logging and check the most recent customization or form event first.
Error fixDiagnosing and fixing SyteLine session timeout errors
SyteLine session timeouts come from one of three independent layers: the IDO Data Service session timeout on the app server, the IIS/application pool idle timeout for the web (Mongoose Web) client, or a load balancer/proxy idle timeout in front of a CloudSuite hosted environment. Fixing the wrong layer is the most common mistake - you need to identify which layer is actually expiring the session before changing anything.
Error fixResolving SyteLine multi-site replication conflict errors
A replication conflict in SyteLine's multi-site architecture means the same record (commonly an item, customer, or BOM) was changed independently at two sites between replication cycles, and the replication engine could not automatically merge the two versions. Check the replication conflict log first to see which record and which fields collided, then decide which site's version should win before resuming the queue.
Error fixSyteLine error: invalid site or item not valid at this site
SyteLine is a multi-site system where items, warehouses, and most master data are site-specific by design. This error means either the item has never been extended to the site you are transacting in, your user login does not have access to that site, or the current site context on the form does not match the site of the referenced record. Add the item to the site via Item Sites, or correct the user's site security, and the error clears.
Error fixTroubleshooting SyteLine MRP and APS regeneration that fails or hangs
A SyteLine MRP or APS run that fails to complete, hangs indefinitely, or errors partway through is most often caused by data integrity problems (a BOM loop, an item with an invalid lead time or missing routing), a scheduling engine (APS) process that is stuck or resource-starved, or a concurrent MRP run conflict. Check the MRP/APS log first for the specific item or job it stopped on before assuming it is a system capacity issue.
Error fixFixing SyteLine's 'transaction out of balance' GL posting error
This posting error means SyteLine tried to create a general ledger journal entry where total debits do not equal total credits, which the GL will not accept. The most frequent causes are a missing or misconfigured account in the automatic account determination setup (COA mapping), currency rounding on multi-currency transactions, or a source transaction (inventory, job cost, AP/AR) that only partially calculated its cost or tax components before posting.
AI for ERPAI for Infor SyteLine and CloudSuite Industrial
Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.
Stuck on Infor SyteLine (CloudSuite Industrial)?
Talk to engineers who work inside Infor SyteLine (CloudSuite Industrial) every week, and who build private AI that answers these questions from your own ERP data.