3 Replies Latest reply on Mar 18, 2015 2:49 PM by philmodjunk

    Help: How to organize table data for multiple users?

    TonyTrevisonno

      Title

      Help: How to organize table data for multiple users?

      Post

      I am planning out a new database that will be hosted by FileMaker Server 13 and accessed by multiple users using FileMaker Pro and possibly WebDirect.
       
      This is the scenario:
      1. I have a table that stores a bunch of item numbers.
      2. I have another table that stores parent/child relationships regarding the items in the item table.
       
      3. A user performs a search and gets a bunch of results from the items table.
      4. The user will select one or more items from the search results.
       
      5. The user will click a button that says something like "Create BOM" or "Create Tree" -- you get the idea.
      6. The script will then use the data in the parent/child table to build the tree and present the result to the user.
      7. The building of the tree and its presentation to the user will be done in a separate table.
       
      Question:
      If the tree building table is stored on the server and my script imports the records to this table to build and display it, won't these records interfere with the records of another user if another user is also doing the same thing from their client? Do I need to have the tree building table stored locally on each client? The users will subsequently be manipulating and interacting with the records presented to them in the tree so I need to manage these records individually for each user. I'm not sure how I should organize this.
       
      I hope that's enough info. Let me know if more details are required.
      Thanks
      TT

        • 1. Re: Help: How to organize table data for multiple users?
          philmodjunk

          All of these tables should be on the server.

          Whether your "tree building table" will result in one user's data interfering with another depends on how you set up your system to manage them and you can set it up to keep the records from one user from interfering with another. Each user's records in this table, for example could have a field that contains the account name of the user that created them. The value in this field can then be used to keep one user's set of records from interfering with another.

          • 2. Re: Help: How to organize table data for multiple users?
            TonyTrevisonno

            @PhilModJunk

            Yeah, I was wanting to avoid doing something like that. I guess I don't have a choice. I have another solution where I use Postgresl as the server and FileMaker as the client. I designed a 'client' file in FileMaker that pushes and pulls data from the Postgresql server as required. It works quite well for that solution. In this case, I want everything on the server if possible. I'll have to work something out where I can isolate each users records in separate tables. Your suggestion, or something like it, I will have to save as a last case scenario -- although, I don't know what the alternative would be at this point.

             

             

            • 3. Re: Help: How to organize table data for multiple users?
              philmodjunk

              I strongly, strongly advise AGAINST "isolate each users records in separate tables"! This is NOT what I am recommending. Keep all of your records in the same set of tables for all users. But then use the tools any relational database comes with to keep different subsets of records accessible for different users.

              That's why you would "mark" all records for a given user with their account name. That, for just one example, allows you to script finds that only find records with the user's account name. In another example, it allows relationships and portal filters to limit related records to only those with the current user's account name. And you can set up manage security to limit the user's access to only "their" records. This can be to the point that the use never even knows other records exist..