New Db Setup Tables/Forms

[BKC468]

I'm setting up a new database for all of the projects that I have and
subsequently I need to track the employees involved with each project.

I started out creating a table of employees (( Empl ID (Primary), Fr Name,
Lst Name, Title, Function, Manager, Pay Rate.))

Then I created a table for the projects ((Proj ID (Primary), Description,
Type, Proj Value, Begin and End Proj Dates ))

That was easy, then I had to create a table for each project that shows (Empl
ID, Hours Budgeted, Hours Worked, Hours Available )) - I have 32 of these
tables. I had to (i think) because I can have one employee working on 15
different projects.

I want to create a single form that populates the Project Tables. I want to
have something like a pull down menu that I can select the Project from and
update it monthly. But I cannot get all of these tables to load to a single
form. Can someone give me some direction here??

 

[Jeff Boyce]

One table for each project, ... hmmm ... that sounds like a ... spreadsheet!

Access is a relational database. If you feed it 'sheet data, you won't get
very good use of its relationally-oriented features/functions. In fact,
both you and Access will have to work overtime to come up with work-arounds
(i.e., kludges) to try to get things done Access isn't designed to do.

You can pay now (learn about relational database design and normalization,
then apply it to make your data well-normalized), or you can pay later
(every time you need to start a new project with your design, you'll have to
modify your tables, forms, queries, reports, etc.).

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[BKC468]

I know, I know but there are so many projects and one employee can be a part
of multiple projects. I've pulled some relational information to paroose
again over the weekend. I'll try again to rebuild the tables which is what I
know I need to do.

One table for each project, ... hmmm ... that sounds like a ... spreadsheet!

You can pay now (learn about relational database design and normalization,

then apply it to make your data well-normalized), or you can pay later
(every time you need to start a new project with your design, you'll have to
modify your tables, forms, queries, reports, etc.).

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I'm setting up a new database for all of the projects that I have and
subsequently I need to track the employees involved with each project.

[quoted text clipped - 18 lines]

single
form. Can someone give me some direction here??

 

[Jeff Boyce]

Consider the following ... (I'm guessing that your projects are similar to
mine...)

tblProject
ProjectID
ProjectTitle
Project Description
... (other project-specific attributes)

tblEmployee
EmployeeID
FName
LName
... (other employee-specific attributes)

trelAssignment
AssignmentID
EmployeeID
ProjectID
FromDate
ToDate

This approach lets you assign one employee to many projects and many
employees to one project.

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I know, I know but there are so many projects and one employee can be a
part
of multiple projects. I've pulled some relational information to paroose
again over the weekend. I'll try again to rebuild the tables which is
what I
know I need to do.

One table for each project, ... hmmm ... that sounds like a ...
spreadsheet!

You can pay now (learn about relational database design and
normalization,

then apply it to make your data well-normalized), or you can pay later
(every time you need to start a new project with your design, you'll have
to
modify your tables, forms, queries, reports, etc.).

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I'm setting up a new database for all of the projects that I have and
subsequently I need to track the employees involved with each project.

[quoted text clipped - 18 lines]

single
form. Can someone give me some direction here??

 

[tina]

aha, Jeff, so you're the one who helped my boss figure out how to give me 17
things to do at once! <g>

Consider the following ... (I'm guessing that your projects are similar to
mine...)

tblProject
ProjectID
ProjectTitle
Project Description
... (other project-specific attributes)

tblEmployee
EmployeeID
FName
LName
... (other employee-specific attributes)

trelAssignment
AssignmentID
EmployeeID
ProjectID
FromDate
ToDate

This approach lets you assign one employee to many projects and many
employees to one project.

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I know, I know but there are so many projects and one employee can be a
part
of multiple projects. I've pulled some relational information to paroose
again over the weekend. I'll try again to rebuild the tables which is
what I
know I need to do.

One table for each project, ... hmmm ... that sounds like a ...
spreadsheet!

You can pay now (learn about relational database design and
normalization,
then apply it to make your data well-normalized), or you can pay later
(every time you need to start a new project with your design, you'll have
to
modify your tables, forms, queries, reports, etc.).

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I'm setting up a new database for all of the projects that I have and
subsequently I need to track the employees involved with each project.
[quoted text clipped - 18 lines]
single
form. Can someone give me some direction here??

 

[BKC468 via AccessMonster.com]

Thanks Jeff - I can tweek the empl and project table to get this, but can you
tell me what you are emplying by TrelEmployee? Did you mean Table?

Consider the following ... (I'm guessing that your projects are similar to
mine...)

tblProject
ProjectID
ProjectTitle
Project Description
... (other project-specific attributes)

tblEmployee
EmployeeID
FName
LName
... (other employee-specific attributes)

trelAssignment
AssignmentID
EmployeeID
ProjectID
FromDate
ToDate

This approach lets you assign one employee to many projects and many
employees to one project.

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I know, I know but there are so many projects and one employee can be a
part

[quoted text clipped - 25 lines]

 

[Jeff Boyce]

many-to-many, doncha just love it?!

Regards

Jeff Boyce
Microsoft Office/Access MVP

aha, Jeff, so you're the one who helped my boss figure out how to give me
17
things to do at once! <g>

Consider the following ... (I'm guessing that your projects are similar
to
mine...)

tblProject
ProjectID
ProjectTitle
Project Description
... (other project-specific attributes)

tblEmployee
EmployeeID
FName
LName
... (other employee-specific attributes)

trelAssignment
AssignmentID
EmployeeID
ProjectID
FromDate
ToDate

This approach lets you assign one employee to many projects and many
employees to one project.

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I know, I know but there are so many projects and one employee can be a
part
of multiple projects. I've pulled some relational information to paroose
again over the weekend. I'll try again to rebuild the tables which is
what I
know I need to do.

Jeff Boyce wrote:
One table for each project, ... hmmm ... that sounds like a ...
spreadsheet!

You can pay now (learn about relational database design and
normalization,
then apply it to make your data well-normalized), or you can pay later
(every time you need to start a new project with your design, you'll have
to
modify your tables, forms, queries, reports, etc.).

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I'm setting up a new database for all of the projects that I have and
subsequently I need to track the employees involved with each
project.
[quoted text clipped - 18 lines]
single
form. Can someone give me some direction here??

 

[Jeff Boyce]

Sorry, I used a prefix that usually stands for "table-relationship" (AKA,
junction table, resolver table). These are used to handle many-to-many
relationships (and if an employee can work on many projects ... over time
.... and a project can have many employees working on it, you have a
many-to-many relationship).

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks Jeff - I can tweek the empl and project table to get this, but can
you
tell me what you are emplying by TrelEmployee? Did you mean Table?

Consider the following ... (I'm guessing that your projects are similar to
mine...)

tblProject
ProjectID
ProjectTitle
Project Description
... (other project-specific attributes)

tblEmployee
EmployeeID
FName
LName
... (other employee-specific attributes)

trelAssignment
AssignmentID
EmployeeID
ProjectID
FromDate
ToDate

This approach lets you assign one employee to many projects and many
employees to one project.

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I know, I know but there are so many projects and one employee can be a
part

[quoted text clipped - 25 lines]

single
form. Can someone give me some direction here??

 

[BKC468 via AccessMonster.com]

Thank you so much, I think this work. I will reply to you again when I have
finished loading the information to say thank you!!

Sorry, I used a prefix that usually stands for "table-relationship" (AKA,
junction table, resolver table). These are used to handle many-to-many
relationships (and if an employee can work on many projects ... over time
... and a project can have many employees working on it, you have a
many-to-many relationship).

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks Jeff - I can tweek the empl and project table to get this, but can
you

[quoted text clipped - 37 lines]

 

[tina]

well, from a design standpoint, yeah - but from a work standpoint, not so
much! on the other hand, in this economy i'm grateful to have a job at all,
so i'll do my 17 tasks and keep my mouth shut!

many-to-many, doncha just love it?!

Regards

Jeff Boyce
Microsoft Office/Access MVP

aha, Jeff, so you're the one who helped my boss figure out how to give me
17
things to do at once! <g>

Consider the following ... (I'm guessing that your projects are similar
to
mine...)

tblProject
ProjectID
ProjectTitle
Project Description
... (other project-specific attributes)

tblEmployee
EmployeeID
FName
LName
... (other employee-specific attributes)

trelAssignment
AssignmentID
EmployeeID
ProjectID
FromDate
ToDate

This approach lets you assign one employee to many projects and many
employees to one project.

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I know, I know but there are so many projects and one employee can be a
part
of multiple projects. I've pulled some relational information to paroose
again over the weekend. I'll try again to rebuild the tables which is
what I
know I need to do.

Jeff Boyce wrote:
One table for each project, ... hmmm ... that sounds like a ...
spreadsheet!

You can pay now (learn about relational database design and
normalization,
then apply it to make your data well-normalized), or you can pay later
(every time you need to start a new project with your design, you'll have
to
modify your tables, forms, queries, reports, etc.).

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

I'm setting up a new database for all of the projects that I have and
subsequently I need to track the employees involved with each
project.
[quoted text clipped - 18 lines]
single
form. Can someone give me some direction here??

 

[John W. Vinson]

aha, Jeff, so you're the one who helped my boss figure out how to give me 17
things to do at once! <g>

And if the tasks table has a Priority field... they're all set to 1, right?

 

[tina]

LOL, you must know my boss, too, John! <g>

And if the tasks table has a Priority field... they're all set to 1, right?

 

[Jeff Boyce]

The best thing about having all tasks as Priority 1 is that I get to decide!
My boss doesn't like hearing that, but he understands...

Jeff

LOL, you must know my boss, too, John! <g>

 

[John W. Vinson]

LOL, you must know my boss, too, John! <g>

Anne used to occasionally use the notorious DEF priority system:

Do Everything First

 

[David W. Fenton]

And if the tasks table has a Priority field... they're all set to
1, right?

Worse still:

Some are set to priority 1 and others to priority 2.

Guess which ones the boss will ask you 2 hours later if they are
done yet? If you guessed PRIORITY 2, you're right!

In other words, boss's often aren't very good at setting priorities.

 

[tina]

wow, an understanding boss! ...will you trade? <bg>

The best thing about having all tasks as Priority 1 is that I get to decide!
My boss doesn't like hearing that, but he understands...

Jeff

 

[BKC468 via AccessMonster.com]

Thank you for the input. IT WORKED! I did have to take another look at my
relationships. Now everything is running smoothly. I was able to build my
Reports and Forms and some Query's yesterday with ease.

The only thing left for me to do now before I'm done is to setup the
switchboard.

Thanks again.

Sorry, I used a prefix that usually stands for "table-relationship" (AKA,
junction table, resolver table). These are used to handle many-to-many
relationships (and if an employee can work on many projects ... over time
... and a project can have many employees working on it, you have a
many-to-many relationship).

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks Jeff - I can tweek the empl and project table to get this, but can
you

[quoted text clipped - 37 lines]

 

[Jeff Boyce]

Not so sure you want this one ... he's also the one who says "Now!"

Jeff

 

[tina]

well, i get that anyhow, but without the understanding bit...so i keep
reminding myself that i'm grateful to have a job, and there are lots of
folks out there who'd be overjoyed to be working again, for any kind of a
boss!

 

[Jeff Boyce]

It used to frustrate the dickens out of the fellow I used to work for when
he asked me if "XXXX" was possible ("can you do XXXX?"), and I'd think about
it for a bit, spread my arms as wide as appropriate, and answer "Yes I can
do it, ... and it will cost THIS much!"

As I pointed out to him, he'd better know that up front if he wanted to make
good use of scarce resources.

I miss him!

Jeff