Welcome to the forum!
Shouldn't it be possible to create a database in Access where we can connect all the information for a project such as the different contacts, the address of the project, address of the various contacts, and many other details about projects?
It certainly is possible. However, Access is not a glorified spreadsheet, and it requires thinking about and organizing data differently from Excel. All relational databases including Access need to follow the rules of
normalization.
And since you are just starting out, here are some general recommendations
1. Do not use spaces or special characters in your table or field names.
2. Do not use Access reserved words or symbols in your table or field names. Here is a
list.
3. Do not use lookups (list/combo boxes) in your tables. This
site details the problems doing so can cause. It is best to leave list/combo boxes for your forms.
4. All user interaction with the database should be through forms; the users should never see your tables.
And one personal recommendation.
1. Use an autonumber, primary key field in every table and make sure to give it an appropriate name rather than just "ID". That autonumber should have no significance to your users.
So now to your database...
You say that you have: project architect, contractor, owner. These are actually roles a company or person plays.
I assume that you will have actual names of people and/or companies, so by normalization rules, you would put them in 1 table.
tblPeople
-pkPeopleID primary key, autonumber
-txtPrimaryName (name of company or last name of an individual)
-txtSecondaryName (first name of an individual)
-txtAddress
-txtCity
etc.
Now since you may have many people associated with a company, you need to relate those people to the company. You may not need this table, but more than likely, you will.
tblPeopleRelate
-pkPeopleRelateID primary key, autonumber
-fkMPeopleID foreign key to tblPeople (must be a long integer number data type)
-fkSPeopleID (must be a long integer number data type)
In the above table, you would have 1 record for every person in a particular company. You would designate the company using the fkMPeopleID whereas you would use fkSPeopleID for the individual.
Now to your project. You will need a table to hold the basic project information
tblProjects
-pkProjectID primary key, autonumber
-txtProjectName
-ProjectNumber (you will have to decide on the field type)
Now since many people/companies are associated with a project, you need a table to relate the project and people
tblProjectPeople
-pkProjectPeopleID primary key, autonumber
-fkProjectID foreign key to tblProject (must be a long integer number datatype)
-fkProjectID foreign key to tblPeople (must be a long integer number datatype)
-fkRoleID foreign key to tblRole (must be a long integer number datatype); this field designates the role a person or company plays relative to the project.
tblRoles (just a list of roles-each as a record: project architect, contractor, owner)
-pkRoleID primary key, autonumber
-txtRoleName
