dbTalk Databases Forums  

Conditional value list strategy

comp.databases.filemaker comp.databases.filemaker


Discuss Conditional value list strategy in the comp.databases.filemaker forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Bill Jaynes
 
Posts: n/a

Default Conditional value list strategy - 12-29-2003 , 09:48 PM






Hello,
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
users.

Thanks for any guidance,
Bill

Reply With Quote
  #2  
Old   
Paul Bruneau
 
Posts: n/a

Default 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>...
Quote:
Hello,
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
users.
Don't use the names of things as the fields upon which your
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.


Reply With Quote
  #3  
Old   
Bill Jaynes
 
Posts: n/a

Default 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,
Bill
Quote:
Don't use the names of things as the fields upon which your
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.

Reply With Quote
  #4  
Old   
Bill Jaynes
 
Posts: n/a

Default Re: Conditional value list strategy - 12-30-2003 , 05:10 PM



Thanks Paul,
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.
Bill
Quote:
Don't use the names of things as the fields upon which your
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.

Reply With Quote
  #5  
Old   
Musicmad
 
Posts: n/a

Default 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.

Chuck Boody
===========
In article <cf397f78.0312301510.56d002c4 (AT) posting (DOT) google.com>, Bill
Jaynes <bjaynes (AT) montanaport (DOT) net> wrote:

Quote:
Thanks Paul,
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.
Bill

Don't use the names of things as the fields upon which your
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.
--
Musicmad


Reply With Quote
  #6  
Old   
John Weinshel
 
Posts: n/a

Default 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.

--
John Weinshel
Datagrace
Vashon Island, WA
(206) 463-1634
Associate Member, Filemaker Solutions Alliance


"Bill Jaynes" <bjaynes (AT) montanaport (DOT) net> wrote

Quote:
Thanks Paul,
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.
Bill

Don't use the names of things as the fields upon which your
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.



Reply With Quote
  #7  
Old   
Bill Jaynes
 
Posts: n/a

Default 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,
Bill
"John Weinshel" <john (AT) datagrace (DOT) biz> wrote


Quote:
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.



--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.