Imports, replace, SQL updates, will fail if they try to edit a field of a record that one user is editing.
This seems to be obvious, and it's a accepted fact. It makes sense technically… but what about usage sense, on second thought it's seems needed and strange, that non user editable field get also locked !
For instance, I've a script that imports products warehouse availability in my main table. User constantly search, filter etc based on stock, therefore, for performance reasons I had to put it in the main table (if unstored calc, or 1 to 1 relationship would be much faster in filemaker I wouldn't need this, but that's not the case). The problem is that this import can fail because one user is locking the whole record (an we have no way to get which record(s) it is)
This does not make sense, since that availability field can't be edited at all by the user, therefore there's no need to lock it even on a non committed record.
Therefore I ask that we (developers), can set some fields has being immune to record lock. This will help a lot, improve data coherence.
Of course this will work for all caching field we have to use to get some speed in sorts, finds etc.
I know it's against normalization, but it's the way to get performance in filemaker unfortunately, of course I'd trade this for much better performance in search, sorts that will free us to this caching mechanism.