Conditional value list strategy - 12-29-2003 , 09:48 PM
I have a conditional value list set up for some automotive parts
(thanks to John Weinshel for helping me see the logic). The idea is
that there is a set of vehicle repair areas such as ignition, tires
etc. These are in a custom value list since they need to appear in a
certain order. Then there is a large list of common part names. The
user can associate, say, spark plugs, coils and condensers with the
ignition work area. We're not dealing with particular exact parts but
generic names to make it quicker to enter line items in an invoice.
The part names are records in a parts file with a category field as
the right side of the relationship to the work areas. The parts appear
in a portal in the work area file (creation allowed); the user adds
new part names by filling in the empty line at the end of the portal.
This is working well except for how to handle the case of a user
wanting to change the name one of the work areas. Suppose they wish
to change "Air Conditioning" to "AC". Right away, the associated parts
are "lost". The workaround involves a button that sets a text field to
all the associated parts; the user then modifies the work area name in
the value list and then re-enters the part names that are visible in
the text field. Probably no user wants to deal with that I'm hoping
someone can show me a different strategy that would be easier for
Thanks for any guidance,
Re: Conditional value list strategy - 12-30-2003 , 09:40 AM
bjaynes (AT) montanaport (DOT) net (Bill Jaynes) wrote in message news:<cf397f78.0312291948.1429556e (AT) posting (DOT) google.com>...
relationships are built. Instead, use unique identifiers such as an
auto-entered serial number. Then you can change the names all day long
and have no problems.
Re: Conditional value list strategy - 12-30-2003 , 12:05 PM
Thank you Paul,
I see what you mean, now for the implementation.
Happy New Year,
Re: Conditional value list strategy - 12-30-2003 , 05:10 PM
Do you have a suggestion of how to work the left side of the
relationship? As I mentioned, values need to appear in a custom order.
That's why the left side is, so far, a hard coded custom value list. I
guess I don't know how to keep the order of the value list if it comes
from fields that are indexed by the serial number route you suggest.
Doing things that way has always resulted in alphabetic value lists; I
bet I'm missing something obvious.
Re: Conditional value list strategy - 12-31-2003 , 01:39 AM
The simple solution, if I understand your question correctly, would
probably be to create a hard coded number in the "left side" database
that is the number of the order you want things to appear. Then sort
on that in your relationship or popup or whatever.
In article <cf397f78.0312301510.56d002c4 (AT) posting (DOT) google.com>, Bill
Jaynes <bjaynes (AT) montanaport (DOT) net> wrote:
Re: Conditional value list strategy - 12-31-2003 , 11:59 AM
If I'm following correctly, you should be able to use 'Also display values
from' to build your VL, and sort by that field (the actual name), rather
than by the ID. The second field is used only for display (and, in this
instance, sorting); only the ID is used as a field value.
I can't see your entire solution, but it sounds like bad voodoo to allow
users access to key values like 'air conditioning' vs. 'ac'. I would work
hard to give them less access. That probably means restricting their menu
access, via a password and group scheme, to 'Editing Only', so that record
creation and data entry are controlled by scripts, which leaves validation
in the developer's hands, where it belongs.
Vashon Island, WA
Associate Member, Filemaker Solutions Alliance
"Bill Jaynes" <bjaynes (AT) montanaport (DOT) net> wrote
Re: Conditional value list strategy - 01-01-2004 , 09:15 PM
Thanks John and Chuck,
I'm working on the sort-on-second-value solution. I think I need to
offer users access to product naming because they are the business
owners and have their own issues about names and naming jargon. And
anyway, it's only for ease of entry and doesn't affect the monetary side
of the db.
It is tempting to deny access to the left side key here but only if I
really think I've met people's needs for product categories.
Thanks for the input
& happy new year,
"John Weinshel" <john (AT) datagrace (DOT) biz> wrote
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG