Best Practice db development - newby to Access

[CraigJ]

I have been using Access for a awhile (Novice entirely) and got tired of having to rely on SQL and various other Programmers to tweak and develop our home grown DB. I have decided to delve heavily into development work myself and am loving it. In essence we are a property management company who run statements monthly for each building. Each building has the same basic features and vary in size , number of units within each building varies. Our old DB was written in 2003 Access so is outdated and "wobbly" and I would like to rewrite the entire thing from scratch with latest technology - Access 2013. The question is, do I create a table for each building ( 16 of them) in isolation to each other? Each building or table gets fresh value inputs ( per unit within the building) monthly.

[pbaldy]

In general, no, never. You'd have a single buildings table with a field to designate the building. Read up on normalization. One link among many:

http://r937.com/relational.html

[CraigJ]

In general, no, never. You'd have a single buildings table with a field to designate the building. Read up on normalization. One link among many:

http://r937.com/relational.html

Thank you very much Pbaldy for taking the time to reply. I sincerely appreciate it.

[pbaldy]

Happy to help and welcome to the site by the way!

[CJ_London]

if your db was originally written by professionals and is working well (even if it is creaking at the seams a bit), the chances are the data structure is OK, so I would be inclined to start and build from there. I'm not saying don't change it, just start from there. Before making changes understand why it is structured that way. Simply adding a new field is one thing, changing the relationships between tables is another.

And ensure that by taking this on, you don't neglect your business.