Error when managing container field storage change

Questions
1

I am attempting to change the storage settings for a series of container fields. Most fields transfer OK, but I'm getting the following error message with some of them—
"Record cannot be changed, because another user is modifying it."
The fields in question are storage fields in a dedicated table where they are used to populate matching global fields—the standard setup up used by many.
I don't quite understand how these fields could be in use by anyone, since the only user is me and all I'm doing is this one task.
If anyone can shed some light I'd be most grateful.

2

I've done some further testing and I think I may have stumbled upon a bug. It goes like this:

  1. If I try to convert the storage option for two or more fields at a time from the same table, FM reports the error, as per my initial post.
  2. If I transfer one field at a time the transfer is completed without error.
  3. If I transfer two or more fields at a time, each from a different table, the transfer is completed without error.
  4. If I transfer 3 fields at a time, 2 from one table and 1 from another, 2 out of 3 transfers are completed.
  5. The defining issue seems to be more than one field at a time from the same table.
  6. Looking more closely at the error message reported it reads: "Opening record resulted in error (301): Record cannot be changed, because another user is modifying it." Based on that, it appears that FM tries to open the record, but fails because it is already open.
  7. Taking the above a step further, FM must pause to take a breath every now and again, because when this issue first cropped up I was attempting to transfer multiple fields (13 or 14), all from the same record and it successfully transferred 3 or 4, not just the first field.
    Very happy to receive any comments or feedback from anyone. I'm proposing to file a bug report on this with Claris, so any supporting comments could be included.
1 Like
3

This error is usually sent when someone else is already modifying the same record or when you have another window open on the same record. If none of these situations are occurring, then it looks like when you are changing more than one field in a single table, theses changes would be done in parallel, thus the first change would block the other. It's only a theory that needs to be verified.

1 Like
4

A very reasonable theory though, and accords with my testing.

5

The fileMaker 19.4 release notes mention something which sounds similar to this.

1 Like
6

Yes. I have received notification from Claris that the issue has been addressed in the latest update.

1 Like