Contract Management Database (1 Viewer)

Hi,
Would anyone have a simple contract management database that they would be willing to share. I am fairly new to Access and would not have the knowledge to create one from scratch. I have been using Excel, but that is not the best tool to use I am finding.
Something simple with a contract name, start date, end date, review date and some other bits and pieces to record vendor name and contact details and an area for attaching supporting docs etc if possible.
Any help would be much appreciated.

Check this page out for a data model (there are two Contract Management templates listed - see the first column down the page a bit)

http://www.databaseanswers.org/data_models/

Bob,
Many thanks for the info.
Excuse my ignorance but is what you pointed me to something which I can click on and an access database application will appear and be useable or do I have to create something?
Regards

You have to create the Access database. This is only the table structure and you build the tables and everything else. It does say that there is an Access database available if you email the email address on the link to the top left where it says there is an Access DB available but I've heard that the email address doesn't seem to be active. So, you might not be able to get it.

OK thanks Bob....appreciate you taking the time to respond and for the great advice.

Bob,
Sorry but one last question.
What do PK (Primary Key?), PF (?), FK (?) signify in the model please ?

MonkeyMan said:

Bob,
Sorry but one last question.
What do PK (Primary Key?), PF (?), FK (?) signify in the model please ?

Click to expand...

PK is PRIMARY KEY - that is the key within the table which identifies a unique record (row of data). I usually let Access handle those so I use a surrogate primary key consisting of an autonumber.

FK is FOREIGN KEY - that is essentially a field in a table which stores the primary key of another table.

For example -

Table Name - EMPLOYEES

EmployeeID - Autonumber (PK)
FirstName
LastName

Table Name - ROLES
RoleID - Autonumber (PK)
RoleDescription

Table Name - EmployeesRoles
EmployeeRoleID - Autonumber (PK)
EmployeeID - Long Integer (FK from Employees Table)
RoleID - Long Integer (FK from Roles table)

So you see how, in the EmployeesRoles table it has its own primary key (and some will use a composite key made up from EmployeeID and RoleID and that is okay too as long as the employee roles table doesn't have its PK stored elsewhere. Technically it is okay then too but you would have to store both fields in that other table where using an autonumber PK in that instance would be a single field). Then the EmployeedRoles table stores the EmployeeID from the Employees table and the RoleID from the Roles table and that ties everything together. The relationship links would be from EmployeeID in the Employees table to the EmployeeID in the EmployeeRoles table and the RoleID from the Roles table linked to RoleID in the EmployeeRoles table.

I hope that helps clear it up a bit.