A single lookup table should work fine for this. I don't see a need to create a different table for each lookup. Field structure
ID (int, indexed) ItemType (varchar 25, indexed) ItemStored (char3) ItemDisplay(varchar 25) The field lengths above are not set in stone, and I am assuming your profile table does not have any one-to-many relationships with the drop-down data (there's only oging to be one marital status per individual profiled, for example). Data would be stored in the profile table in individual dedicated fields. I don't see a reason to have a foreign key in the lookup table. To edit all lookups you can develop a simple data grid that dumps them all out, sorted, or get fancy and make one data grid per field name. Drop-down display results from a simple select statement with one filter for itemtype. ItemType gets the form field name, perhaps. ItemStored is what is put into the db and ItemDisplay is what is visible to the user in the drop-down. I suppose if you were a fanatic about data normalization you would create a table for 'lookups' and have it contain only ID and ItemType. Then your lookup table has an indexed ParentID field (foreign key) replacing the ItemType field. Not something I would do unless I was trying to impress a professor in a class project. -- [EMAIL PROTECTED] Janitor, The Robertson Team mysecretbase.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion 8 - Build next generation apps today, with easy PDF and Ajax features - download now http://download.macromedia.com/pub/labs/coldfusion/cf8_beta_whatsnew_052907.pdf Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:288734 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
