Auto pop textbox on 2nd form with same value as 1st form

[Arvin]

Hello ...

The answer would be Org - Dept - Funcgrp - Emp

 

[Kryst51]

What kind of relationship is between each?

Org (Many) to Dept (One)

Then

Dept (Many) to Funcgrp (One)

Then

Funcgrp (Many) to Emp (One) ?

 

[Arvin]

Org (Many) to Dept (One)

Then

Dept (Many) to Funcgrp (One)

Then

Funcgrp (Many) to Emp (One)

it would be

Org (One) to Dept (Many)

Then

Dept (One) to Funcgrp (Many)

Then

Funcgrp (One) to Emp (Many) ?

 

[Kryst51]

Is a director and a manager also an employee?

 

[Arvin]

Is a director and a manager also an employee?

Yes they are ..... I think I'm starting to understand where you're going with this ....

 

[Kryst51]

And is your manager really associated with a dept and org? or can that come through the employee table.

 

[Kryst51]

There are a couple of ways of thinking, and you'll have to choose which you want, some people would say that normalization requires all employees, regardless of type in the same table, others would say that the separation you have is fine. You can make it work either way, but you have to decide that now, as it is going to effect how and when you make relationships with the other tables.

 

[Arvin]

Hmmm ...... interesting point ... you see ... I created the tables based on reportng structure .....

For example ... I report to my manager who reports to the director who then reports to the VP....

Would it be better for the long run and the sustainability of the app to have them ( all employees ) in one table?

thank you in advance.....

 

[Kryst51]

Well, as I said, it's your choice, But as a suggestion, read up on normalization. A database does not necessarily work the way things occur in real world or in a spreadsheet. Your table design and relationships are very important though. If we can get them normalized, then queries and forms can handle the look and feel of the db, basically what you see and how your used to seeing it. So I'll help you but you have to make the decision. Google normalization and read up before going any further. Then let me know, or makes some changes your self and post your revised version. I am doing some revisions here, but as I don't know your data, I have to ask a lot of questions.

Edit: Personally, I would put them all in one table, but that is my personal preference.

 

[Arvin]

Okay ... I did i you suggested and it (normalization) makes waaaaaaaaay more sense now ...thank you

Here is my issue ... currently, we use a spreadsheet to track employee time on projects/tasks/activities....each employee has their own spreadsheet...which is linked to a Dept summary workbook ... which displays the results of each employee and dept ( see attached )

My task is to take what we have today and make it a better ... I know i know ..... very cliche... but hey ....

 

[Arvin]

Opps .. i cut myself off there .....

My goal is to create one application that all employees can access..for example ...

Employee can

Create new enteries for themselves
Update existing enteries
View reports for them self

Mangers can.

View all enteries made by only the employees that reports to them
Create new enteries
Update existing employee enteries
View reports that reflect the dept that they manage.

Directors can

View all enteries made by all employee int he department
View all reports
No creating or updating required.....

 

[Kryst51]

Alright then, this is possible, but it will take work, so first choice, how do you want to handle the empoyee, manager, director, etc. bit.

 

[Kryst51]

1st.... Cheers to the power of GraySkull!

I forgot to say Thanks!!! Fun huh?

 

[Arvin]

Alright then, this is possible, but it will take work, so first choice, how do you want to handle the empoyee, manager, director, etc. bit.

hmmm......I would like to keep them as is please ....

I guess i will have to create a Password field in the Director table and Mgr table also in order to give them access to the app ...

 

[Kryst51]

hmmm......I would like to keep them as is please ....

I guess i will have to create a Password field in the Director table and Mgr table also in order to give them access to the app ...

That could be one reason to put them all in one table, or have a separate password table that stores all passwords, although that would work better if all employees werre one table. Why don't you work on normalization with your current layout, three separate tables, and I will see if I can do one with the one table, then You can see what the differences are, and if nothing else, maybe learn a little more from it.

It's definitely a learning experience for me too.

 

[Arvin]

sounds like a plan ... I will start on that now ...

 

[vbaInet]

That could be one reason to put them all in one table, or have a separate password table that stores all passwords, although that would work better if all employees werre one table.

Saving passwords in tables. Not so sure of this one kryst51. One can easily import that table into another database.

 

[Kryst51]

Saving passwords in tables. Not so sure of this one kryst51. One can easily import that table into another database.

Just as any stored password, The OP already has passwords stored in tables. How else should the OP do it? I don't have any experience using passwords.

 

[vbaInet]

If we consider how windows (for example) handles permissions and rights then maybe we could be on the right path. I don't think you need seperate tables for Directors and Managers. Create a table for storing EmployeeRole which will have three records; "Director", "Manager", "User". Create another table to store the lists of database users. So it will have "User Name", "Role", "DateAdded". To keep things simple assign one role to each user. When the user logs in it will run a function that will reference the EmployeeRole table using DLookup and disable/enable buttons where necessary. Your function will have a list of all the command buttons that it should enable and disable and its paramter will be "Role". You use a Select case to check against that and perform the relevant enable/disable operations. You will need to call this function for everyform that is opened. Or just have a switchboard and disable/enable where necessary. Just a suggestion, what do you think?

 

[Kryst51]

If we consider how windows (for example) handles permissions and rights then maybe we could be on the right path. I don't think you need seperate tables for Directors and Managers. Create a table for storing EmployeeRole which will have three records; "Director", "Manager", "User". Create another table to store the lists of database users. So it will have "User Name", "Role", "DateAdded". To keep things simple assign one role to each user. When the user logs in it will run a function that will reference the EmployeeRole table using DLookup and disable/enable buttons where necessary. Your function will have a list of all the command buttons that it should enable and disable and its paramter will be "Role". You use a Select case to check against that and perform the relevant enable/disable operations. You will need to call this function for everyform that is opened. Or just have a switchboard and disable/enable where necessary. Just a suggestion, what do you think?

I think the OP is a very new access user, and there is debate over the best way to handle this, I have seen some on this forum, so speaking of functions and such is probably a little over the OP's head. OP, if I am wrong, please accept my humble apologies. I agree, It would be my first intuition to use one table with roles, which is how I'll work on my end, but the OP wants to do it the way they currently have it, and I think it would be OK, and if it turns out not to work well, then learning will have occurred.