This is not a FMGo issue, but a design issue.
Fields that users can modify should not be used as key fields. You should have an auto-enter key field. It could be a serial number field or use get(uuid).
I suggest describing what you want to do in more detail. We might be able to suggest a more workable approach for you.
Is the used field from previous record good? Will it use the previous record from the found set? Or if another user added a row, would it use that one if it is the previous record?
That doesn't really help. Can you provide an example of what you mean by that?
What do you mean by "good"? What criteria determines that?
The three fields in the first pictured are entered by a user. After that they press a button that shows matching rows of these values in another table through another layout (2nd picture). When the user adds a row in the 2nd picture, the values from picture one are used.
The problem is: if a 2nd user changes the values in picture 1, these changed values are entered in the rows that are entered by the first user.
I hope that this clarifies my question. My temporary fix is to duplicate the record shown in picture one when a user launches FMP. But that is not ideal..
Fields which are unique to each user are called Global fields (which is just a storage option on the field). Global fields are "session based" as well a "user based". that means if the file is closed the user will need to re-enter the values to get the same results. However user "A" can have different values than user "B".
(and follow the links at the bottom of that page)
(and follow the links on that page, too)
Still more info is needed.
Are both layouts based on the same table?
these changed values are entered in the rows that are entered by the first user.
Your second picture shows 4 fields in a form view followed by a table view or portal of 3 more fields. What "rows" are you talking about in that second picture?
As a guess, "2016 week 49" appears in weeknummer in the second picture, "Amsterdam..." appears in Locatie and "5108" appears in Postnu. Is that the "row" that you are describing?
If both layouts are based on the same table, then editing data on one layout is also going to produce identical changes on the other and that will be the case whether the changes are made by one user or many users.
At a guess, you need to re-evaluate your design here so that the user's unique ID is part of the process. You could require all users to open the file with a password for example and then use get ( accountName ) to identify each user. This could then be used to keep data entered by one user separate from data entered by another. but I have such a limited understanding of what you are attempting to do, this suggestion could be wrong or at least far from ideal.
A description of what each user is supposed to be doing (give us the "big picture") might clear up a lot of unanswered questions.