sounds good to me... but, uh, where do I do that? I'm in design view for tables and I have no idea where to write that script. lol =D
Anyway, while on the relatively same topic; with the same example above, is it possible to do the opposite? From the AllTbl, how does one extract all the rows with a Year value of, say, 07 into a separate table?
I'm thinking that of having a Master List of all Units that only contains the Year, Unit code and Name. Then having separate tables per year containing year, unit code, unit name, unit details, etc.
Unrelated, if I have three fields, each of which is a list box, is there a way for the column on the left to narrow the options made available on the list box to the right?
DO NOT have three tables here. You don't want to have three tables that you merge into one - just have the one table exactly as you have defined AllTbl. You should have data in columns - not in table names. The temporal data (2008, 2007 etc) should not determine how many tables you have and what their names are.
Sorry, I wasn't psychic and didn't realise he was making a "three table system". I thought he was importing data from different sources in order to create a single table as you described... the AllTbl, which tbh, is a terrible name
Haha. I do admit to being ignorant about databases. But using tacky filenames? =p
Anyway, I finished reading about relational design. Seems like I was wrong to base the functionality of the db strictly to what can be made readily on tables. Just realized that a good combination of forms and queries will be what I need and that I should stop treating the tables as if they were my front-end.
I spent the past couple of days putting lots of info in the tables, now I'm gonna go redraw the plans and normalize the existing tables for easier queries. =D