I agree with some
@mike60smart some I disagree.
Normally the PK in all tables is an Autonumber, but you have Text Fields set as the PK
This should read "Often" instead of "Normally." There are advantages of using an autonumber, but there are advantages of using a natural key at times. I have worked on massive ERPs where the PKs are text. That by itself is not a problem.
Also, you would normally link the Parent PK to the related FK in the table that contains related Child Records
That I would change from normally to "Always". If a "link" means a relation then you only do this from PK to FK. You can do a "join" on whatever you want, but not the same thing.
You also are using Lookup Fields in your tables and again this is wrong. Search Google for "The Evils of Lookup Fields in Access Tables"
IMO this should be changed from "wrong" to "absolute nightmare!" It is even worse than wrong.
This shows the magnitude of the problems.
PrjPhase to tbl_Item_Activiity is almost correct. You are going from PK to FK. But a link only happens if you go PK to FK of the same data type. ID Prj Phase is numeric and so project phase should also be numeric but it is text, but it is not storing the Project Phase name it is actually storing the project phase ID. You just cannot see it. It is storing a project phase number (1,2,3..) but unfortunately it is storing it as text.
Here is the lookup "SELECT [PRJ PHASE].[ID PRJ PHASE], [PRJ PHASE].[PROJECT PHASE] FROM [PRJ PHASE]; "
Bound column: 1
Now it gets worse and even more confusing. Tbl_CMC joins by Project Phase name not the ID. However it does not even do that, because it too stores the ID. Here is the lookup
SELECT [PRJ PHASE].[ID PRJ PHASE], [PRJ PHASE].[PROJECT PHASE], [PRJ PHASE].[ID] FROM [PRJ PHASE] ORDER BY [ID];
Bound column 1
So it would appear possible to create a join since you would see names in both fields, but you cannot even do a join since tbl_CMC stores a hidden numeric (stored as text). Wow!
The purpose of the relationship window is TO ENSURE REFERNTIAL INTEGRITY. It also defaults the join for future queries, but that is simply a feature and not it real purpose. These relations should be enforced and correctly established.
I strongly concur that you fix this before going further. This is truly a nightmare in the making. The farther you get in development, the worse this will be.
You need to establish clean table relations and then enforce them in the relationship window. I would strongly recommend adopting a better naming convention. I like
ID_Prj_Phase for the PK
ID_Prj_Phase_FK as the foreingn key.
You have a PK
ID Prj Phase and then a second field Project Phase. You then have pseudo foreign keys with the name Project Phase which is the name of a field that is not the PK
All of this makes you DB super confusing.