First of all, I assume since you "haven't done much multi-user stuff" that you are probably sharing the database via FMPro, not FMServer. However, the behaviour you are observing would be the same either way.
Second, if both users have the database open they can each work independently on separate layouts, with separate found sets, etc.
Third, any record either user is currently editing is locked for other users—necessary to avoid conflicting with one another. Once the editing user commits their changes the record is released and those changes can be seen by other users.
Fourth, if the second user is working with all records open and the first user creates a new record and commits it, then that new record will "appear" the second user's found count. However, if the second user is working with a subset, then any new record created by the other user will not be included in that subset—even if it fits within the found set the second user is working with (names beginning with B or whatever). FM will simply add the new record to the currently hidden records. To have the new record included in the found set (i.e. to "refresh the list view found set"), the second user would have to perform their find again.
Thanks for the thorough summary of FMP behavior. I was unaware of your fourth point about how list layouts behave with a found set vs. all records. That's exactly what I'm experiencing. Is there any way to get the thing to behave like it does when your found set is ALL records, short of putting a big ugly "Refresh" button on the layout that the user is forced to click when he wants to see the latest greatest data?
None that I can think of. Your users need to be aware of the behaviour and realise the possibility that the other user may be creating relevant records.
When a user performs a find, the "found set" is not "the latest and greatest data", it's the data I found and am working with. Consider that I may have found 10 records, omitted 3 of them, extended my found set to add all the "b's" or whatever and gotten 6 more, then constrained it down to 4 with another find, then added a new record that wouldn't have fit my original find criteria...
In short, a "found set" is defined by what was "found", not by the find criteria (or subsequent extends, constrains, omits, new records, etc.).
Believe it or not, this makes sense much more often than it doesn't. You may be trying to solve a problem that works out not to be a problem (and quite arguably is a benefit) if you work with found sets as they are intended to work.
As a user, having the found set that you "crafted" change unexpectedly is a much bigger problem than having records appear that you weren't expected. "Show all" is different in that you haven't "said" what records you want, or "crafted" that found set, so it's okay to add new records to "all records".
It's not a bug, it's a feature. When you find records, you're getting a picture, not a movie.
I get all that. It makes sense that a user who's "crafted" a found set would not want it contaminated by other users adding or deleting records. In my case, however, it's a simple filter really. (All records where Status ≠ "Resolved".) Is there an alternative way of being able to show dynamically the entire table where that condition is true?
I'm thinking that if I create a new TO of my table and self-join to the original table, with the relationship being setup so that the key field is a new global with the contents "Resolved" which would be related to the Status field with the ≠ operator? If I did that and modified my list-view layout so that it viewed the table from the context of the new TO, would Show All Records give me the subset that I want? If so, then perhaps any new records that were added by other users would magically appear?
Why do you want a list view?
What is the user doing that makes this detail important?
Note that, if you were to use a portal rather than list, and the portal is based on your filter criteria, it would always contain the correct contents though once again you may need to do something to refresh it.
I'm a list-view kind of guy I guess. I realize you can do a filter when you define a portal. Maybe I'll have to go that route.
Just to close this out, I walked my dog last night and came to the understanding (correctly I hope) that self-joins won't filter a list-view layout, because FileMaker regards the second TO as being RELATED to the first TO, therefore a portal is the only interface that will provide a window to the "related" records. So I will need to toss out my list-view layout and build a portal instead.
Thanks for all your help, everyone.
Hmm not so fast. Should you have a computer displaying a list of entries on a Kiosk, you could still use a list, with the same find and sort done by a script called by a Install OnTimer Script. It's not your case, I know, but for the sake of completeness I had to mention it.