8 Replies Latest reply on Aug 22, 2016 5:57 PM by coloradokid

    Multiple user problem


      I have built a database that tracks jobs and have designed it to enter all data from the jobs layout using scripts and portals. Spent a lot of time building it only to find out that only one person at a time can now use it due to this one location data entry scheme. I have to many scripts to have to rework it. Any Ideas??

      My Tables are:



      Line Items

      Thanks Don

        • 1. Re: Multiple user problem

          Filemaker is a multi-user database.  Many users can access the database and work on it at the same time.  However as is good DB practice, only one user can modify a record at one time.


          Please explain what the (second) user is doing that leads you to think that only one user can use the file at one time.

          • 2. Re: Multiple user problem

            Well all data entry is done on one layout using portals at my main job layout. So it is being done at the job level and only one record per job so basically they would be trying to access the same record at once although they may be trying to create new categories or line items. but i guess we are all fighting to get into the same record.

            Thanks Don

            • 3. Re: Multiple user problem

              You can give each user their own different record on the data entry layout and then avoid record locking issues in most cases.


              In other cases, you can use global fields for data entry with a script that transfers the data from the globals to regular fields elsewhere in your solution.

              • 4. Re: Multiple user problem

                What version are you using?



                • 6. Re: Multiple user problem

                  Thank You Phil for your advice. The way I built my solution the only way for me to do this is to take the user to the job they need to work in and then capture the UUID and then create a new blank job and paste the UUID in a sense creating a duplicate job. I tested this theory and it seems to work fine. Can you think of any thing it might harm to do it this way? I believe this fake job thats assignable I will keep with the user so that anytime he or she logs in she will go to his personal page and I ever delete this user I will have it delete her job as well.

                  What do you think?

                  And Thank you for always giving your time to us!


                  • 7. Re: Multiple user problem

                    I would prefer using global fields for this so that duplicate records--especially records with the same UUID are never, ever created--to much potential for problems.

                    • 8. Re: Multiple user problem

                      Phil I built this all around the premise of Jobs so the first and only layout you go to is the main job screen. In the construction world we have a thing called CSI numbers. CSI numbers are basically a catalog of different construction disciplines. So in my database you first go to the job that you will be working in and you pick a CSI number and then you start by adding a category to that CSI such as West Exterior Elevation. Then you add line items to that category. We work on very large jobs and my main data entry layout is part of the Jobs table. Well often there will need to be other people working on different CSI in the same Job and thats where my problem lies. I hear you on creating globals that then go and set the new records in a script. But that would require rewriting a lot of scripts and to build some more scripts. Furthermore a lot of the data shown on the Jobs screen would not be available.

                      What do you think of this? So the user logs in and then sees my nav portal that shows the list of jobs. They select the job they wish to work in and my script goes there grabs the UUID and then it creates a new job and paste the UUID in the new job record. Then all data that pertains to that job but is in other tables such as categories and line item populate my portals. And then in exiting that job a script erases the uuid for the fake job and then deletes the fake job.

                      I know it sounds funny but if all was done through scripts I don't see where it would be able to get off.

                      Phil also this might be easier to discuss by telephone. I would be willing to pay for your time.

                      I am hoping for an easy way to fix this without writing a lot of new scripts/relationships and so on.

                      Thanks Don