Record locking issue

As far as I understand you don’t prevent multiple users from accessing the card window to edit e.g. a Task of the same record - is that correct?

Do you have something other than “the last user clicking the Save button wins” technique?

I guess one could add a flag to the record whenever a user enters the card window to update the record in order to stop other users from going there at the same time - but how do you make sure that the flag resets if a user is disconnected for whatever reason and therefore is unable to release the flag lock of that record?

You could capture the mod count when you open the card, and warn the user if somebody has modified before the commit if another user has changed the record.

Which means that this is how you decided it should work in Karbon?

Do you consider circumventing FileMaker’s record locking a feature of Karbon?

Circumventing the default record-locking behavior is an unfortunate side-effect of having a system that enforces rules. You could devise a check-in/out scheme that could duplicate the record-locking feature, but that’s likely not worth the effort. Checking the mod count should be good enough for most cases.

We leave many things–like this–up to the developer to decide.

OK, I see, thanks.
I tried this check-in/out system just to found out that there’s no (?) way to be sure to reset the check-in flag after a user is disconnected for whatever reason.

Are you saying that you can’t do Open Record while the edit card window is taking place, then commit it right before sending it to the Kontroller?

That’s another approach that can work, although it’s not 100 percent.

Meaning it (Open Record script step) is not 100% FileMaker standard record locking? Or is it something else that makes it not reliable?

There’s a brief delay between committing the record from the UI file and locking the record in the transaction where another user could sneek in an update, causing your utility window to be out of sync. The likely result in this scenario is that one user would get a record lock failure because the other transaction is likely still in process.


Do you agree that these are the two main alternative behaviors to choose from?:

  1. FileMaker standard record locking
  2. Last edit wins.

I’d agree with that.

Hi all, I’m a newbie to Filemaker and I’ve been looking at various approaches to development in FM, and Karbon, with it’s scripts and separation of concerns, is the closest I’ve seen to the techniques I’ve used in the past (I have a lot of experience with ‘traditional’ RDBMS such as Ingres, Oracle and MS SQL going back to the 1980’s.) Please bear with my ramblings below, I want this to be as clear as I can make it (especially for myself!), but as I’ve limited Filemaker experience all code is pseudo-code/pseudo SQL.

The implicit locking / transaction mechanism in Filemaker seems a little alien to me. I’ve always used explicit Begin / Commit / Rollback transaction statements (using SQL embedded in e.g. C or a 4GL). Maybe there is a request to Filemaker to add these specific scripting commands…

From my experience, ‘last edit wins’ is not a strategy you’d want to allow, especially if it’s silent, as it can lead to lost information and confusion for the user (“I changed that yesterday, where did my change go?”)

Dave’s suggestion of capturing the mod count is exactly what I’ve used to avoid this scenario, with a message to the user to say that the record has been updated elsewhere. In SQL I’d use something like:

UPDATE my_table
SET … update_count = update_count + 1
WHERE … AND update_count = $update_count

IF ERROCODE = 0 AND ROWCOUNT = 0 // successfully updated nothing
<MESSAGE TO USER -> Record has been updated elsewhere, try again>


Would it be possible to implement something like this using the current script/kontroller based mechanism?

I also have a couple of questions about how the locking mechanism works, although may this is the wrong forum for that. I’m trying to get an in-depth understanding of the locking mechanism, and this technical deep-dive is good as is Todd Geist’s intro here:

You can’t implement a solution where the last change wins unless you completely remove the ability for users to edit records in browse mode. If someone has a record locked there simply is no way to write to the record. This is why @tobejazz proposed two alternative behaviors (i.e., you must pick one or the other).

If you remove the ability to lock records in browse mode, then you should certainly use the mod count to determine if the record has changed since you began editing. In this scenario editing is done using global fields or temporary schema before being written to the database. You’ll either need a rule for: a) refreshing your temporary schema with current info, b) overwriting any changes made by other users since your began your edit, or c) allowing the user to choose what to do.

The default record-locking behavior is very powerful and prohibits conflicting edits, but it is also a major pain at times.

Thanks for the swift reply. My lack of experience here suggests I must simply revisit the Karbon videos and try a few things (with the script debugger).