On 2013 Jan 29, at 20:40, Alex <[log in to unmask]> wrote:

> FMPA 12
> Mac/PC
> 
> I'm redesigning from scratch a database I originally developed in FMP 8. It has 300+ value lists in various value lists/files. I am putting all those values into 1 table in the new design. The client needs to be able to access the values to occasionally change them. For example, change -swimming pool- to -private swimming pool-. 
> 
> I've looked at and tried many value list options available in the community but I can't seem to find one that works from a served (FMP 12 Server) file or will hold the value when there is more than one value set on a layout. It's possible I haven't adapted them correctly but after 3 weeks of trying, I give up.
> 
> I need single choice, multiple choice and conditional values, usually all three types on the various layouts.
> 
> Does anyone know of a solution that they can point me to?
> 
> Thanks, -Alex


I can't resolve this particular problem for you, Alex, but I can alert you to a problem that might have escaped your attention, namely the consequences for existing records of clients changing value lists on their own.

Let's say you've got 10,000 records, and on 200 of them the client has already clicked on a checkbox for "swimming pool". Then the client goes into the definition of the value list and changes that value to "private swimming pool". All 200 of those records will still have the old value ("swimming pool") in them, because changing the value list has no effect whatsoever on the data. It does, however, have an effect on the data display, since a checkbox-formatted version of that field will no longer display anything called "swimming pool". It's no longer one of the available values from that value list. So it won't show up for those 200 records. It'll stlil be there, but you'll have no way of knowing it. You can try to do a Find for "swimming pool", but once you're in Find mode there's no such value to check.

A lesser problem occurs if you've formatted the field as checkboxes or radio buttons and allowed exactly enuf space on screen for the values you supplied to neatly fill the field. Along comes the client, who adds 2-3 more values, and suddenly the ones at the end of the value list get shoved out of view, since the space you allocated to the field isn't big enuf to display the client's new, larger list.

Neither of these problems is insoluble, but they do require a super-diligent client, which in my experience is relatively rare.