Normalizing (and fixing) a large, messy DB

[JoeBruce]

Thanks for the quick reply, plog. I read it the other day and have been pondering your advice.

To answer your main follow up question, permits relate to the climbers who climbed and which routes they climbed. A permit can relate to a guide company, but only if one was present for the climb (in the context of data, that means a null value should be acceptable here). I might play around with the idea of a guide company relating to tblRouteRecords, especially in the context of your forms advice.

What you wrote about forms makes a lot of sense. I have done something similar, just not in the order you describe. I will experiment a bit and see what I can come up with.

I've realized the issue with forms based on queries; I generally use tables too, but when looking at the record set for the form I guess I turned it into a query. I had been referencing the other database I made, and saw that main form used a query. Now looking closer I do not think that form pulls data from more than one table, so the query there is superfluous. For this database, I've reverted back to the form based on a table; my subforms all seem to be select queries, though.

[gemma-the-husky]

Out of interest, do you know how much your firm spent on the database.
How many forms are there? How many queries?

Re-engineering a large database is an extensive and difficult project. Re-engineering a bad database is hard to justify. You may as well start over, but you have to convince someone that it's worth the effort and cost.