Multi-user new records visible for others users

Questions
1

2 users viewing the same list-layout with their own found set.
When user A adds a record, it sometimes is added automatically to the found set of user B. Not always.
When is it added to the found set of others and when it is not? I haven't found but it intrigues me. Who knows the answer for me?

2

FM offers a live view of data and therefore updates other clients when one client adds a record. This happens instantly most of the time, but not always.
In order to offer users control over what they see in a found set, I put a button on layouts, linked to a ‘refresh window’ command.

1 Like
3

A found set will remain static if it is based on a find or go to related record command. A found set can be dynamic if it is based on the show omitted records or show all records command. Committing a record can play a role too. Network latency affects how fast a new record can appear.

I have no idea how exhaustive this list is.

Hope this helps.

3 Likes
4

A found set is WINDOW specific so a change of layouts within the same window will retain the same found set.

When a user add/edits/deletes a record in a list view, other users will immediately see these changes WHEN THE CHANGE IS COMMITTED.

An explicit commit can be scripted.

The default implicit commit is the more typical situation. Until a user clicks outside the edited field, the change is not committed. A common scenario is an edit in a portal; until the users clicks outside the portal or code executes an explicit commit, other users don’t see the change

Changing layouts or windows will also perform this implicit commit. Or you can script a commit.

From a simplistic view, a SAVE button with any command attached (to make the button live), when clicked, effectively does an implicit commit by having a user click outside the field on that button.

These situations may be why other users are not always seeing live changes consistently.

5

The Refresh window may not be doing what you believe; the button click is doing an implicit record commit which creates the update. The refresh is likely unnecessary overhead