I'll give you the tech answer plus a couple of more specific ideas.
To keep history properly, you must carefully normalize your tables. By that I mean that things that don't go together don't get stored together.
You have a tenant table. If you need a person's history then you cannot get rid of obsolete tenant entries.
You have properties that can be occupied or not. That means you cannot keep property data with tenants because you could never track unoccupied properties.
You don't explicitly say this, but I'll be you have cases where a tenant has left and come back, or has moved from one unit to another. This means that you have to keep things fluid.
Now, the way to do this is actually quite simple, but it will take a little time to set up.
You need three tables. One table telling you about tenants - name, any identifying info like SSN, original references, etc. One table telling you about your properties - address, size (sq.ft), motif, and individual apartment number if that is the way the property runs. One table telling you about your leases.
The lease table needs to contain pointers (foreign keys) to join a tenant to a property. Lease entries can contain current rent rate and pointers to a tenant and a propery. Also effective dates. I would have at least three. Start date, putative end, and actual end. You could make that four by using putative and actual start dates separately if that makes sense in your case. Also flags (Yes/No) for "lease broken prior to end date" and "new lease because of rate change" or "evicted for damage" or any other event that would cause the lease to change.
I would call a rate change a new lease because the contract between you and your tenant changed when the rate changed, but that's just me. But if you want a rate history, you need to keep the old entry (with the old rate intact) around for your records.
Now, build a big join that links all three on their respective keys. You might need to do this in two stages because you have two joins to do. One is Lease-to-tenant. The other is Lease-to-Property.
Now, to get a list of all currently occupied properties, you need to build a query against that joined lease query to find all leases for which the current date is greater than the actual start date and less than the actual end date. Or you could include a flag in a lease entry that says "active" - in which case you don't need two end dates. (But you might need an estimated end date if you want to project availability.)
To get a history of tenants for a given property, you need a query against the joined lease query that selects the property and sorts the tenants by the actual start date.
To get a history of a tenant, you need a query against the joined lease query to select the tenant, sorted by actual start date.
Suppose you need to perform repairs. There, you have a separate repair table that has a pointer to either the lease or the property itself. But once you set it up, always referencing the same table! Me, I would link a repair to a property. But there is also no reason you couldn't ALSO link to a tenant if one was in the property at that time. (Not instead of!)
Suppose you need to track rent. There, you have a separate rent payment table that has a pointer to the lease. Here, you could simplify matters if you used the "occupied properties" query rather than the master lease query as the basis for a drop-down list so when you record a payment, you can quickly find the address/tenant account to be credited.
Now, the theory: Why so complex? Because this is the business model of a property leasing company. You have tenants. You have properties. You have contracts/leases. You have payments. You have repairs. Each of these things represents a part of your business. So if you want to make an Access database that supports your business, you want its design to match your business model. If you didn't have this model, you would instead implement something else. But the idea is that if you want to track items in your business, you need a table in which to track them. The normalization part is how you assure that you can keep histories on business elements.
For instance, I think you can see that the design I suggested allows you to track a non-current tenant or a non-occupied property. It also allows you to track a previous tenant's rent-payment history. It also allows you to track maintenance on any property to allow you to see if there is a trend. Using dates, you could even try to match up maintenance to tenants to see if you can show that a particular tenant is rougher on your property than others.
