5 Replies Latest reply on Sep 7, 2012 1:35 PM by philmodjunk

    Long time for value list updates?

    BryanN

      Title

      Long time for value list updates?

      Post

      So I have a customer contacts table and associated layout for customer contact information data entry. Works great.  No issues.

      In our Jobs table/layout, I use a pop up value list based off a customer contact field (a calculated field to add company name and contact name together, aka Jim's Company - Jim Moore) in order to input the correct customer ID into the FK field for the Jobs table.  I've noticed that if I go to the Customers layout, make a couple of changes (perhaps to company or contact name) and try to select them in the value list pop up, that the contact info isn't there.  It doesn't happen all the time, but it does happen at least 50% of the time.  However, if I close my session, re-open the DB and login, the info is updated in the popup/value list and I can go on my merry way.  

      Is there any settings I can mess with in order to ensure that any of my value list pop ups (of which I have at least 4 or 5) update fast fast as possible for my users?

        • 1. Re: Long time for value list updates?
          philmodjunk

          It sounds like you are trying to access the values in the value list before the changes you have made have been committed(saved). Try this experiment to see if I am correct: After editing a field used in the value list, click a blank area of the layout before trying to drop down the list.

          If that works, you need only commit the records--which can be done by script via an OnObjectSave trigger each time you edit a field that is used to supply data to your value list.

          • 2. Re: Long time for value list updates?
            BryanN

            It sounds like you are trying to access the values in the value list before the changes you have made have been committed(saved). Try this experiment to see if I am correct: After editing a field used in the value list, click a blank area of the layout before trying to drop down the list.

            If that works, you need only commit the records--which can be done by script via an OnObjectSave trigger each time you edit a field that is used to supply data to your value list.

             

            Yup.  That was it.  Here's a question:  should I be altering the storage options for any of these fields from minimal to all?

            • 3. Re: Long time for value list updates?
              philmodjunk

              That's actually an indexing option. Normally, you can leave that option untouched. FileMaker will automatically update the indexing options as needed as you use this field in relationships, value lists, sorts and searches--the operations that require indexing.

              • 4. Re: Long time for value list updates?
                BryanN

                That's actually an indexing option. Normally, you can leave that option untouched. FileMaker will automatically update the indexing options as needed as you use this field in relationships, value lists, sorts and searches--the operations that require indexing.

                 

                So if in my error, I had changed some of the fields to 'all', is there any reason to go back and change everything back to 'minimal' or is it fine to let it go?  (our db is only about 8.4 Mb right now)

                • 5. Re: Long time for value list updates?
                  philmodjunk

                  For relatively small database files, it rarely makes a significant difference. Here are how it can affect things:

                  1) The file will be a bit larger if the fields are text fields and you put a lot of data into them. The "All" option generates a second value list of all the unique words in your field. As you put more and more data into this field for more and more records, this data structure can become quite large. (You can enter gigabytes of text into a single text field...)

                  2) any "mass data changes" take more time to update when the field(s) involved are indexed. If you import all your data into a new empty copy of your database, the indexes are all rebuilt from scratch during the import. The larger and more numerous your indexes, the longer the import process takes. If you delete 1000's of records, these same indexes have to be updated to remove values from the index if the remaining fields do not contain that value or word. A replace field contents operation that modifies a field for a large number of records will also take longer if the field being updated is indexed and full indexing takes more time than minimal.

                  On the flip side, any searches or sorts that only reference indexed fields will be many times faster than those that use fields that are not indexed.

                  In all of the above cases, any noticeable gain or loss in performance is an exponetial function of the amount of data in your file so I wouldn't worry about this unless you start seeing a noticeable delay in getting a layout to update after one of these actions.

                  Also note that for most databases, the kind of operations that are adversely affected by indexing are much less frequent than those where indexing improves performance.