6 Replies Latest reply on Apr 5, 2017 11:51 AM by philmodjunk

    Growth leading to future problem

    SteveKeiser

      I have a number of places in my database where I have a list with a selection field and then in the header a selector which performs batch operations on all selected items. Here is the problem: Now that we have grown and there are significantly more users, I can anticipate that at some point more than one person will be trying to do a batch operation on the same table at the same time. So, I need to change how this is done, but have no idea about how to do so. So I am soliciting ideas from all you FM wizards.

        • 1. Re: Growth leading to future problem
          Jason Wood

          I think you're going to have to give up a little more about what you're actually doing.

          • 2. Re: Growth leading to future problem
            Jaymo

            I agree with Jason. Why are you running these batch processes? What do they do? Maybe a FileMaker Script can provide substitute functionality if we know what it is you are trying to accomplish.

            • 3. Re: Growth leading to future problem
              SteveKeiser

              Okay, for instance in one place I have a list of sales items. A sales rep can look through the list and click on the selection button and when completed he goes up to a selector on the header and selects "Make Sales Entries for All Selected Items". This fires off a script which then makes an entry in the sales table for each item which was selected and then deselects all of the items. There are multiple batch commands he can do once he selects each of the items.

              • 4. Re: Growth leading to future problem
                Jaymo

                The same thing can be accomplished with a FileMaker Replace Field Contents script step. The only concern is record locking. If someone else is editing one of the records then that record will not be modified.

                • 5. Re: Growth leading to future problem
                  Jason Wood

                  So currently every record has a field for the purposes of marking the record as "selected". And yes this is going to cause both record locking issues and problems when different people are trying to select different records in similar lists.

                   

                  Get rid of that field. Use a button to select/deselect the record. When you select the record, you just want to add the record key to a return-separated list in a global field. Use conditional formatting to show you if the record is selected or not.

                   

                  This means the items table is never modified, and there is no conflict between multiple users.

                   

                  You'll need to remember to deal with (or prevent) situations where old selections are in the field even though they're no longer in the found set (so you won't "see" them as selected).

                   

                  For deselecting records, you'll have to substitute out the id, which means you should either put start and stop characters on each line, or make sure there's a carriage return at the beginning and end of the field.

                  • 6. Re: Growth leading to future problem
                    philmodjunk

                    For working examples of what Jason is describing, take a look at the "check boxes with scroll bars example in the following file. You don't have to use a portal for this technique as is done here, but if you look at the script that fires each time an item is selected or deselected, you'll find a calculation that either adds or removes a selected item from the return separated list used to track which items are selected.

                     

                    Adventures in FileMaking #2-enhanced value selection

                    1 of 1 people found this helpful