1 2 Previous Next 28 Replies Latest reply on Apr 14, 2015 2:34 PM by siplus

    Are there any multi-user best practices?




      I'm developing an inhouse solution which will be used by three of four users simultaneously and I'm struggling with a number of issues. The main one is how to allow a user to display search results in a portal without affecting the other users. At the moment if User 1 does a search then User 2, 3 and 4 have the same results in their portal. At the moment I'm using a boolean to mark a field as 'found' and then using that field in the relationship but that clearly isn't going to work for multiple users as they all show the same results.


      Are there any guidelines available to help with developing for multi-users? I've done a lot of searching and have found a few bits of useful information but no single resource that covers everything.


      Any guidance would be much appreciated.





        • 1. Re: Are there any multi-user best practices?

          Set up the portal without the boolean filter in the table occurrence.  Then go into layout mode, double click on the portal and choose filter.  Create a global text field that you can set with your criteria and make the filter (global field = other field in your system). The global is specific to each user so only the person setting the global sees the results.

          • 2. Re: Are there any multi-user best practices?

            Thanks for the reply. Would the relationship be a cross-join (cartesian) and then just apply a filter?


            Any idea on any general information for multi-user development?





            • 3. Re: Are there any multi-user best practices?

              To set the filter criteria, use a global field in the parent table. Global fields are user-specific; each user has his own values. From your description, it appears you're using a standard field, which is why the users are stepping on each other.


              As to "general" multi-user considerations, here are some issues to consider:


              1) Record lock. If user A has a record open, user B will not be able to edit it. Record lock affects not only the single parent record, but any related records that have been touched as well. This will usually only be a problem if you try to run a script that assumes the client running it will have access to any or all records (a very bad assumption). (If the users attempt to step on each other, FileMaker will simply throw up an error and stop the action.) You'll need to trap for error code 301 in your scripting and take appropriate action if the record is locked.


              2) Screen refresh. If user A makes a change to a record, it will not be reflected on user B's screen until that screen refreshes. This is not normally an issue, as screen refreshes happen frequently. However, you can occasionally run into problems if you use unstored calculations, especially calculations more than one level deep. You may find that users' changes don't always update in a timely fashion, so a script with a Refresh Window [ Flush cached join results ] script step can be useful.


              3) Assuming you're using FileMaker Server (and you should be), you might run into issues of users being kicked off by the server if they stay idle too long. Users should get in the habit of closing databases when they're not being used.


              There are probably other things to think about, but I'm not pulling anything up at the moment. FileMaker really is very good about managing a lot of considerations automatically.





              • 4. Re: Are there any multi-user best practices?

                Thanks Mike, that's very helpful. This is the first time I've needed to use FileMaker Server and I'm just starting to see these potential issues. I think this could be a very interesting experience!!!



                • 5. Re: Are there any multi-user best practices?

                  yes, exactly.  The relationship is still a cross-join with a filter applied to the portal.  There are different ways to achieve the same result. 


                  By using the global in the cross join, the filter needs to be set to something in order to view any records in the portal.  Users will see different results depending on what the global is set for. Also, the portal will not be searchable in find mode. 


                  You can also create the cross join without the global and apply the filter to the portal in layout mode.  Users will still see their own results. The filter is gfield= some field in your system or is empty(gfield).  In this way, records will show up in the portal whether you have a value in the global field or not. 

                  Either will work depending on how you want to utilize the portal.

                  • 6. Re: Are there any multi-user best practices?

                    Putting a filter on a portal based upon a cartesian join, in a multi-user environment, when the unfiltered portal would return more than 1000 records, can begin to be a bit slow. There are other techniques available when this happens, but if your related records table is around 200-300 records, using a global as a filter should be acceptable from the performance pov.

                    • 7. Re: Are there any multi-user best practices?

                      @Siplus The unfiltered table will be more like 50,000+ so I'd be interested in your other technique! Thanks

                      • 8. Re: Are there any multi-user best practices?



                        You might consider using the globals to drive the relationship in the graph, instead of simply using them to filter the results on the layout. A portal with 50K records can have real performance issues. Having the globals drive the relationship would prevent the portal from ever attempting to access all 50K records. A "blank" global will link to no records.


                        Bob Gossom

                        • 9. Re: Are there any multi-user best practices?

                          Here you go, instant search on 100'000 client records (sorry for the file size).


                          Enter some text in the search field, press enter or return or tab. N.B. you can also enter "jo sm".


                          If no records found you stay in the search field. If records found, they are displayed in the portal.


                          Click on any name in the portal to select it.

                          • 10. Re: Are there any multi-user best practices?

                            Wow! That's incredibly fast! I need to dissect your file and learn more about Quick Find as the performance is just outstanding.


                            Thanks so much for sharing!



                            • 11. Re: Are there any multi-user best practices?

                              it has been demonstrated that quickFind on 1 million records happens in less than 1 second, so imho one should build around this knowledge - therefore my solution.

                              • 12. Re: Are there any multi-user best practices?

                                That's incredible!


                                Am I correct in assuming that gFindClientKey ensures it works in a multi-user environment? I'm currently dissecting so will soon find out but thought I'd ask just to be sure





                                • 13. Re: Are there any multi-user best practices?

                                  I mainly offer solutions working in a multiuser environment because that's what we are building all day long, if you ask for something that only works in single user I might have to pass because I'm too old to reset my mind and interact with a single-user-world life afterwards


                                  So the short answer is "yes, it will work perfectly in a multiuser environment."

                                  • 14. Re: Are there any multi-user best practices?

                                    quickFind on 1 million INDEXED records.... that is

                                    1 2 Previous Next