Testify!
dsomers said:
Having a history is definitely something I would like to implement later.
This kind of thing is exactly why you want to get your table structure right from the beginning. Adding something new later is almost impossible if your app consists of a million work-arounds. If you have good design & structure, however, you should be able to look at your db and see just where your new idea should fit.
Again, start with a list of what you want it to DO. For example, say one thing you want to DO is be able to track the repair history of any apartment. Don't worry about combo boxes at this point--just about the end results you want: "I want to know the repair and renovation history of any apartment." State it in specific details: "I want to know the date of every service call made on that unit, the nature of the problem, who did the repair work, and how much it cost. I want to be able to see the same information for all units in any one building, so I can tell if it's a unit-specific problem or a whole-building problem. I want to know if the same problem occurs more than once in the same unit or within the same building. I also want to be able to see how much I've spent repairing a building versus how much rent I've made from it"
Then figure out what information it needs to do those things. "I need to know the date of every service call. I need to know which unit had the trouble. I need to know who fixed it. I need to know how much the repair cost." etc., etc...
Group the required info into logical units based on what it's "about". Each table should be "about" one (AND ONLY ONE) thing--one table about buildings, one about units, one about tenants, etc. So when you have a piece of information like "service call", ask yourself if that's about a building, a unit, or a renter... In this case, it's about a unit. Does it make sense to add service call fields to the units table? No, because there might be a lot of service calls for any unit, or one call might be for multiple units, plus the number of calls is open-ended, not a fixed number... so, you need another table that's just about service calls, and since service calls relate to individual units, one field in tblServiceCalls needs to be fkUnitID.
All of this is pen & paper stuff, before you ever open Access. Spend some time figuring that stuff out, THEN ask some more questions after you have some progress to show. That way you'll avoid getting a reputation on the forum as someone who wants it done for you...
Just my two bits worth...
--Preacher Mac