I need to select fee codes from a list. Some fee codes are available to all technicians, some are available only to one trade and some are available to more than one trade, but not all trades. To make it more complicated, some technicians are qualified to bill in more than one trade.

I tried using repeating fields and conditional value lists, but didn

There are a couple of ways: one is to give the user the complete list and let them work it out: surprisingly this often works but depends on the number of options.

The other way is to create a database of the options, each record has a field for the fee code, another for the user code. The user code can have multiple entries separated by returns.

The value list neeeds to be based on a relationship, with the key field in the main file being a global field containing the current user's user code, relating to the user code in the fees code file.

You'll need to get the user to enter or select the user code at some stage for the relationship to work.

Thanks Vaughan

A full list is not an option... there are too many fee codes.

Initially I was reluctant to make the trade a user input(selection), but now I realise that it's the only way to go.

So I followed your second suggestion and it does the trick!

Thanks for your input.

Regards

Dave

I see you've got it working, but you might want to look at this example.

Fee_Trade Codes.zip

Hi, folks! I was rummaging through the posts trying to find out how to do a conditional value list when I found Fenton's excellent attachment above which seems to do exactly what was needed (1 valuelist that is different for each person, based on personal criteria). The sample file uses 3 db's (technicians, feecode--tradecode, and the "main" feetransactions). The valuelist is defined from a field value and only related values (which I have never done before). Now, I'm just trying to get a handle on the concepts...

-- Is this a classic example of a conditional value list?

-- If not, can you point me to a good example?

-- Are conditional value lists always based on relationships?

-- There's a calc field (TradeCodes c)= a related field... I don't think it's relevant to the solution but I was just wondering if this is just a style thing or is there a reason for it... why not just show the related field from which it gets its value?

Even though this appears to me as a very clean and elegant solution, anything beyond a very basic relationship still makes me slightly gel-headed, so any help would be appreciated.

--ST

P.S. If you read this, Fenton.. thanx for the great file you so humbly presented post facto. I'm hanging on to it to learn from. I also just installed Panther so I can work in FM4... thanxagain for the tip on that one, too.

Steve T. said:

-- There's a calc field (TradeCodes c)= a related field... I don't think it's relevant to the solution but I was just wondering if this is just a style thing or is there a reason for it... why not just show the related field from which it gets its value?

If you check the Relationship Window, this calculation is the Left key for your related Value List.

A related field wouldn't be useful as it is not a current field of this file, so it can't be used as the Left key for the relationship.

You therefore definitely need either this calculation or a lookup field to make it work.

Fenton's sampler was intended to answer one querry. Yes, Conditional value lists are always based upon relationship. They don't necessarily always require additional files.

On the contrary, in this instance, we could have involved a 4th file (a Join file) to affiliate Technicians to more than a TradeCode.

Then, rather than a match to the MultiLine Text field in the Technicians file, you could have created a value list based on this Join file.

Also, Conditional Value List are very useful to filter a list based on multiple parameters. In this instance, it would often be based upon a Multikey field.

Check this other sampler.

Note that this sampler is not as clean as Fenton's. Because of Text Indexing limitations (in FM5), the keys would probably break as they are based upon long text strings. It was just a quick demo.

FileMaker Version: 6

Platform: Mac OS 9

Multikey.fp5.zip