Create a Settings table in your solution. Create on Text field for each Value List that you like to be editable. Give user access to this area and populate the field with the information you have in your Value List now. Then change the Value List to show info from table Settings chosen field
You could allow the option in the field/value list set-up to allow the user to edit the value list. However this is not as flexible as it seems, as the custom edits will not carry forward when you import the live data to an upgrade version of your solution, for example. Hence Johan's suggestion is better than the feature that *seems* to be native to Filemaker.
1 of 1 people found this helpful
I prefer one table per value list because each value list is its own set of records. It adds tables, but the size of each table is much smaller. Then I give them access to each table through an "Admin" UI. This is based on a table that is connected to each value list table. They can edit/add/delete on the fly.
In this case, you have to consider the nature of each value in the list. What if they change a value list item from "Car" to "Automobile", for example. Would you want that edit to ripple through your entire system? Especially if you've got scripts or other db functionality based on the word "car".
Developing a table of value lists is great, but it comes with it extra development time. But I find it more valuable and useful for the client in the long run.
EDIT: Another thing to consider: putting the value lists into tables is a good idea for those lists that could change frequently. A value list of Race or Ethnicity or Gender is likely to not change often. In an app I built recently I put every list into a table; in retrospect that was a bit overkill.
I like the idea of each list beings its own table, if for no other reason than (1) an all in one table will have heaps of empty fields, as the number of records will be dictated by the length of the longest list; and (2) adding to any list other than the longest one should be done by filling an empty field on an existing record—but which one? A separate table per list is much simpler to manage.
I also take the point that it is hardly necessary to make a table for some lists—yes/no for example. If it's a fixed list define it as a custom list.
In cases were I don't want to use a table to let the client edit a value list, I use a standard value list. Then give the client an Admin screen with a tab/section to edit the lists.
- I use a global field, putting one copy of the global field on the layout for each value list the client is going to edit. The field label is the name of the list.
- I usually make the field size just big enough to show the Pop up list arrow.
- The field is set as a PopUp menu with "Allow editing of value list" checked.
- I use an onModify script trigger to clear any data in the field.
The one advantage to using a standard value list versus a table/field is the control of the order the items are displayed. They appear exactly as the client wants. When I use a field in a table the appear sorted the way FileMaker wants. Which is not always what the client wants.
I may not have understood the detail of your suggestion, but could you not achieve the same result, with only one global field, duplicated on the layout as many times as you have value lists to edit, and tie each to a different value list?
Also, does the technique not also suffer from the problem that the value list will not be imported when the user's data is imported into an upgrade, for example? (I believe I posted that as a feature request some time ago, but I haven't spotted it coming up on any version release notes.)