> >1) I disagree that with the idea that a single table for lookups makes > >things simple. I have tried this a couple of times, and it has worked > >well until the user says something like "That's fine, but the Tax table > >also needs the amount to multiply by" (usually when you demo the > >finished product ). You now have to add a field to this single > >table, and only use this field for Taxes. > > I've certainly encountered this alot before<s>. In this case, I have > numerous fields that are lookup fields. Some have well under 10 total > choices and I envision no additional parameters needed. I was not convinced > I wanted to create 12 separate little DBFs for these 12 fields, which would > require my creating (and remembering <g>) all of these table names in > addition to the fields names. But I may go in that direction. I probably won't. I'm thinking of something else at the time - having one lookup table for just storing the info, and adding an item into it from time to time, and use it just once at app start, to split the info into arrays; so instead of 12 tiny tables I'll have 12 arrays (with names like l_field when their index is stored into a field named field >). The bad side of it is only that there may be no deletion from this table ever, and its maintenance must be given to a highly reliable person (me? I doubt it :). Just remembering to open all the needed tiny tables in the DE or wherever, is a bore. The arrays are not memory hogs, and may be safely declared public.