Does anyone know if optimistic locking is implemented for SOAP or not? I am trying to solve the problem of SOAP call over-writing changes made by user in UI a moment earlier. Optimistic locking has been implemented for UI and scripts a long time ago.  It could be tested easily: • Open the same record in edit mode in 2 browser tabs • Edit some field and save record in the first tab (get success) • Edit some field and save record in the second tab (get “Record has been changed” error) So essentially Netsuite somehow tracks record state/version during opening editing context via UI/scripts. But there is no hint whether such state/version can be explicitly retrieved or passed via SOAP call. Meanwhile the error RCRD_HAS_BEEN_CHANGED is present in the list of SOAP errors but I have no idea how to reproduce it. There is a hacky solution of always making a get call before any update call to make sure that record hasn’t been changed since the last time I checked. But that still will cause problems if a record gets updated between get and update calls. And for sure I would like to use native locking functionality instead of hacking around.

no, only modify the fields that you want to set, dont try to set all of them

@battk thanks for reply!

only modify the fields that you want to set, dont try to set all of them

sure thing, I am talking only about specific field that I need to set via SOAP - ApprovalStatus for Transaction. So it's really not good when somebody changed it via UI (e.g. to Rejected) and then SOAP call updates it (e.g. to Approved).

no

so the best I can do is to get a transaction before update and ignore the cases when transaction gets modified between get and update calls? Is there any link to documentation so I could officially lose hope? 🥲

no documentation, for it that i know of

Netsuite has implemented optimistic locking for UI and scripts, not opportunistic one 🙂 For optimistic locking you just need to have a 'version' field on a record. Client then sends an update call with the version of record that it is updating. And server either accepts an update if this version is the latest one or aborts an update if a newer record version is available. This is pretty straightforward and easy to implement (especially when it's already done for UI & scripts).

generally you really only want to do updates in one system and send updates one direction

sure thing, but we are talking about ERP system which position themselves as single source of truth for all business data and is supposed to treat API as first-class citizen so I was wondering how come they just didn't replicated the locking mechanisms they already have on UI to API.

you wouldnt know the version without a step to get it first