(I'm sure this topic has been covered but I just can't find it in the forum with the phrasing I've been using.)

I'm trying to follow the Good Practice example of having a separate table store Value List choices but I'm stumped how to set up the TO so multiple tables share the same list, i.e., Table1, Table2, and Table3 each have their own City text field but I want them all to share the same list to draw city choices (from the table, ValueList.)

Mind you these are discrete fields, not a portal set-up.

TIA for your help!

Ciao,

Rich

how to set up the TO so multiple tables share the same list, i.e., Table1, Table2, and Table3 each have their own City text field but I want them all to share the same list to draw city choices (from the table, ValueList.)

Do they need to be related to the selected city? If yes, why? If not, why not simply set up the value list once, then assign it to any field in any table?

Mind you these are

discrete fields, not a portal set-up.

Not sure what you mean by that.

I'm trying to follow the Good Practice example

What is that?

Do they need to be related to the selected city? If yes, why? If not, why not simply set up the value list once, then assign it to any field in any table?

>That's where I'm a little fuzzy: By assigning the VL to its own table then the value would always be visible in the City field, irrespective of which table is "looking" at it; if I were to assign the VL to the City field in say, Table1, and I deleted a record where a city name was used once, then that city name will disappear from the VL, correct?<

Not sure what you mean by that.

>There are a few VL sample files here that used portals. Ignorant as I am, I'm not sure if they hold the answer I'm looking for since the data to be captured would reside in the parent table, not a child one.<

What is that?

>Semantics: there's "Best practice", but since this may or may not be _the_ best way of doing things it's "Good practice." (Hey, I don't make this stuff up--this was told to me by a technical writer.)<

That's where I'm a little fuzzy:

Hm. Imagine how I must feel...

if I were to assign the VL to the City field in say, Table1, and I deleted a record where a city name was used once, then that city name will disappear from the VL, correct?

No, not if the value list is coming from a stand-alone CitiesVL table, where you have pre-entered all the cities you want to use.

This is not much different from entering the cities as custom values when defining the value list (except they can edit the list as data when necessary).

If, OTOH, you have three tables, each with a City field, and you want to have ONE value list using values that have been actually entered into either of the three City fields - well, let's just say that's not going to be easy.

Semantics: there's "Best practice", but since this may or may not be _the_ best way of doing things it's "Good practice." (Hey, I don't make this stuff up--this was told to me by a technical writer.)

Well, I and a few dictionaries happen to disagree with that.

Anyway, I was puzzled by your reference to "the Good Practice example" - I am not familiar with such document. And "having a separate table store Value List choices" may or may not be good practice - depending on the circumstances.

>Hm. Imagine how I must feel... <

Sorry for smiling, but that is funny.

>If, OTOH, you have three tables, each with a City field, and you want to have ONE value list using values that have been actually entered into either of the three City fields - well, let's just say that's not going to be easy.<

Thank you for nailing exactly what I meant. *rhetorical sigh* Why are cool features so difficult to construct? Well, at least we're not playing with MS-Access...

Thank you for nailing exactly what I meant.

Have you considered uniting the three tables into one? Usually, only contacts have addresses. You could also have a separate Addresses "sub-table", used by more than one "main" tables.

Sorry for smiling, but that is funny.

What do you mean, sorry? It was meant to be funny - and you'd better be smiling or else...