Filtered value lists - multiple instances?

[cellmaker]

Having some difficulty with filtered value lists.

I have a table holding "State" names, abbreviations, and countries (per record). I'm using this table as a value list feeder for other tables with those geographic designations. It was no problem setting up the first instance, in which someone first selects the country, and then the state abbreviation is filtered according to the country, so you get a list of state abbreviations only for the country already selected.

I need to have several instances of this in my solution. Do I have to repeat the State table occurrence (and its corresponding sister table occurrence for the filtering relationship) to attach to each table for which I'll use this?

I have a contact table (currently attached to State and its sister State) and will have an event table, plus I don't know how many other instances of needing to borrow from the State table.

Having to repeat this structure every time seems kind of stupid/inefficient, but I can't think of how else I would reuse this related table info.

Thanks in advance for your thoughts.

[RalphL]

All tables in this file can use it. In other files you will have to define a value list using the data from this table. You do not need a new table in each file.

[cellmaker]

I think maybe I wasn't as clear as I should have been.

I'm only using one file and so am not saying I have to recreate the table for multiple files.

If I just wanted a value list based on some random field, that list is available to any and all fields in whatever table. But I want to use a filtered list, which means the filtering table has to "know" which element I wish to filter by, and this is going to require a relational path back to the field I'm working with. So I think I'm answering my own question.

I'll need multiple (identical) instances of the occurrences attached to each field for which I wish to provide a filtered value list. Which is a pain, but is logical.

Is this incorrect thinking? Other ideas?

[The Shadow]

The value list has a "starting from" table, so you will need a new instance for each unique underlying table, but not necess. for each occurrence in the graph.

If I have a table "People" that are both "Customers" and "Employees", a single related value list can be used to lookup part of the address for instance without repeating it in the graph, because it can transform the "Customer" into an "Employee" for a moment to do the address lookup.

[cellmaker]

Sorry for the late response.

OK. If, in the case where you might have many tables requiring this shared information (as here, a table or tables holding address information), would you set up a separate area on your Occurrence Graph making these links, thereby keeping your "main" graph as uncluttered as possible?

(I'm generally having trouble separating the forest from the trees. On the one hand, I want to have as simple a standard ERD as possible, to show how the data would be related under a normalized schema, but interface issues seem to have me constructing bizarre -- sometimes multiple -- paths. Reporting requirements sometimes require that I have an entirely different set of schema, and this is getting quite annoying. MySQL/PHP starts to look really simple and effective as an alternative, minus the HTML GUI difficulties.)

Thanks for any thoughts.