I am looking for some ideas for how to design the layout of the form for
data entry and to display the data for the following situation:
There are many sales associates. A sales associate can work for multiple
companies and work for multiple divisions within each company. Within each
division he can work in multiple departments and within each department he
can work with multiple groups. In each group he works on multiple projects.
All the work areas of each sales associates needs to be input in the form
and displayed in the form - Companies, Divisions, Departments, Groups and
Projects.There are one-to-many relationships between company and division,
division and dpartment, department and group and group and project.
Thanks for all help,
Tom 10 2840
Tom, the question is not so much about the form, as it is about getting the
data structure right.
To my way of thinking, companies, divisions, and departments are actually
layers of the same kind of entity, whereas projects are a different kind of
entity. A project might be shared amongst different departments or
divisions, and could have a starting and ending date, whereas a department
would be a (normally) permanent section of just one division and so forth up
the tree.
If that is so, you might consider making a "Client" table where you can
store all the first kind of entity. It will have a ClientID field as primary
key, and a ParentID field that indicates the immediate parent of this
client. So, if the "client" is a division type, its ParentID would be the
ClientID of a record that is a company.
You would then have another table for Projects, and a table for Staff.
Another table might then have fields:
ClientID: foreign key to Client.ClientID (so can be a co, dept, div,
....)
ProjectID: foreign key to Project.ProjectID
StaffID: foreign key to Staff.StaffID
WorkDate: date the work was done.
Each record says something like this: on August 1 (work date), Joe Smith
(staff) worked for the IT Department (client) on project 49 (whatever that
is.)
If that copes with what you need, you would then have a form with 3 combos
and a text box for the date. Chances are, that's not exactly what you need,
but hopefully it gets you thinking in a useful direction.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message
news:rY****************@newsread1.news.atl.earthli nk.net... I am looking for some ideas for how to design the layout of the form for data entry and to display the data for the following situation: There are many sales associates. A sales associate can work for multiple companies and work for multiple divisions within each company. Within each division he can work in multiple departments and within each department he can work with multiple groups. In each group he works on multiple projects. All the work areas of each sales associates needs to be input in the form and displayed in the form - Companies, Divisions, Departments, Groups and Projects.There are one-to-many relationships between company and division, division and dpartment, department and group and group and project.
Thanks for all help,
Tom
Tom, the question is not so much about the form, as it is about getting the
data structure right.
To my way of thinking, companies, divisions, and departments are actually
layers of the same kind of entity, whereas projects are a different kind of
entity. A project might be shared amongst different departments or
divisions, and could have a starting and ending date, whereas a department
would be a (normally) permanent section of just one division and so forth up
the tree.
If that is so, you might consider making a "Client" table where you can
store all the first kind of entity. It will have a ClientID field as primary
key, and a ParentID field that indicates the immediate parent of this
client. So, if the "client" is a division type, its ParentID would be the
ClientID of a record that is a company.
You would then have another table for Projects, and a table for Staff.
Another table might then have fields:
ClientID: foreign key to Client.ClientID (so can be a co, dept, div,
....)
ProjectID: foreign key to Project.ProjectID
StaffID: foreign key to Staff.StaffID
WorkDate: date the work was done.
Each record says something like this: on August 1 (work date), Joe Smith
(staff) worked for the IT Department (client) on project 49 (whatever that
is.)
If that copes with what you need, you would then have a form with 3 combos
and a text box for the date. Chances are, that's not exactly what you need,
but hopefully it gets you thinking in a useful direction.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message
news:rY****************@newsread1.news.atl.earthli nk.net... I am looking for some ideas for how to design the layout of the form for data entry and to display the data for the following situation: There are many sales associates. A sales associate can work for multiple companies and work for multiple divisions within each company. Within each division he can work in multiple departments and within each department he can work with multiple groups. In each group he works on multiple projects. All the work areas of each sales associates needs to be input in the form and displayed in the form - Companies, Divisions, Departments, Groups and Projects.There are one-to-many relationships between company and division, division and dpartment, department and group and group and project.
Thanks for all help,
Tom
Allen,
Thanks for the response!
I need records to say:
On August 1 (work date), Joe Smith worked for the Industrial Group (group)
of the IT Department (department) of the ABC Division (division) of IT Inc.
(company) on project 49 (project).
On August 1 (work date), Joe Smith worked for the Refining Group (group) of
the Engineering Department (department) of the Construction Division
(division) of IT Inc. (company) on project 27 (project).
On August 1 (work date), Joe Smith worked for the Marketing Group (group) of
the Sales Department (department) of the XYZ Division (division) of IT Inc.
(company) on project 84 (project).
I need a form to enter these records for Joe Smith for August 1.
Thanks,
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:42***********************@per-qv1-newsreader-01.iinet.net.au... Tom, the question is not so much about the form, as it is about getting the data structure right.
To my way of thinking, companies, divisions, and departments are actually layers of the same kind of entity, whereas projects are a different kind of entity. A project might be shared amongst different departments or divisions, and could have a starting and ending date, whereas a department would be a (normally) permanent section of just one division and so forth up the tree.
If that is so, you might consider making a "Client" table where you can store all the first kind of entity. It will have a ClientID field as primary key, and a ParentID field that indicates the immediate parent of this client. So, if the "client" is a division type, its ParentID would be the ClientID of a record that is a company.
You would then have another table for Projects, and a table for Staff. Another table might then have fields: ClientID: foreign key to Client.ClientID (so can be a co, dept, div, ...) ProjectID: foreign key to Project.ProjectID StaffID: foreign key to Staff.StaffID WorkDate: date the work was done. Each record says something like this: on August 1 (work date), Joe Smith (staff) worked for the IT Department (client) on project 49 (whatever that is.)
If that copes with what you need, you would then have a form with 3 combos and a text box for the date. Chances are, that's not exactly what you need, but hopefully it gets you thinking in a useful direction.
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message news:rY****************@newsread1.news.atl.earthli nk.net...I am looking for some ideas for how to design the layout of the form for data entry and to display the data for the following situation: There are many sales associates. A sales associate can work for multiple companies and work for multiple divisions within each company. Within each division he can work in multiple departments and within each department he can work with multiple groups. In each group he works on multiple projects. All the work areas of each sales associates needs to be input in the form and displayed in the form - Companies, Divisions, Departments, Groups and Projects.There are one-to-many relationships between company and division, division and dpartment, department and group and group and project.
Thanks for all help,
Tom
Allen,
Thanks for the response!
I need records to say:
On August 1 (work date), Joe Smith worked for the Industrial Group (group)
of the IT Department (department) of the ABC Division (division) of IT Inc.
(company) on project 49 (project).
On August 1 (work date), Joe Smith worked for the Refining Group (group) of
the Engineering Department (department) of the Construction Division
(division) of IT Inc. (company) on project 27 (project).
On August 1 (work date), Joe Smith worked for the Marketing Group (group) of
the Sales Department (department) of the XYZ Division (division) of IT Inc.
(company) on project 84 (project).
I need a form to enter these records for Joe Smith for August 1.
Thanks,
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:42***********************@per-qv1-newsreader-01.iinet.net.au... Tom, the question is not so much about the form, as it is about getting the data structure right.
To my way of thinking, companies, divisions, and departments are actually layers of the same kind of entity, whereas projects are a different kind of entity. A project might be shared amongst different departments or divisions, and could have a starting and ending date, whereas a department would be a (normally) permanent section of just one division and so forth up the tree.
If that is so, you might consider making a "Client" table where you can store all the first kind of entity. It will have a ClientID field as primary key, and a ParentID field that indicates the immediate parent of this client. So, if the "client" is a division type, its ParentID would be the ClientID of a record that is a company.
You would then have another table for Projects, and a table for Staff. Another table might then have fields: ClientID: foreign key to Client.ClientID (so can be a co, dept, div, ...) ProjectID: foreign key to Project.ProjectID StaffID: foreign key to Staff.StaffID WorkDate: date the work was done. Each record says something like this: on August 1 (work date), Joe Smith (staff) worked for the IT Department (client) on project 49 (whatever that is.)
If that copes with what you need, you would then have a form with 3 combos and a text box for the date. Chances are, that's not exactly what you need, but hopefully it gets you thinking in a useful direction.
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message news:rY****************@newsread1.news.atl.earthli nk.net...I am looking for some ideas for how to design the layout of the form for data entry and to display the data for the following situation: There are many sales associates. A sales associate can work for multiple companies and work for multiple divisions within each company. Within each division he can work in multiple departments and within each department he can work with multiple groups. In each group he works on multiple projects. All the work areas of each sales associates needs to be input in the form and displayed in the form - Companies, Divisions, Departments, Groups and Projects.There are one-to-many relationships between company and division, division and dpartment, department and group and group and project.
Thanks for all help,
Tom
So, you have a couple of choices.
Standard structure
==============
Create:
- a table of possible Group values (records for "Industrial", etc);
- another table to hold the Department values (records for "IT", etc.)
- another table for Division values.
- another table for Companies.
- the main table that will have fields:
o GroupID
o DepartmentID
o DivisionID
o CompanyID
o StaffID
o WorkDate
The disadvantage of that approach is that you can end up choosing nonsense
combinations, such as the Welfare department of a Law form. :-)
Alternative structure
==============
The other structre suggested earlier has the disadvantage that you do have
to go through and enter each division that applies to each company, and then
each deparment of each division, and so on. While this takes more effort
initially, it may provide better data, and it copes with internal company
structures that may not match the standard one (e.g. small companies don't
have departments of divisions.)
Either way, once you have the tables in place, and the relationships between
them, you can start to think about how to create forms.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message
news:5T****************@newsread1.news.atl.earthli nk.net... Allen,
Thanks for the response!
I need records to say: On August 1 (work date), Joe Smith worked for the Industrial Group (group) of the IT Department (department) of the ABC Division (division) of IT Inc. (company) on project 49 (project).
On August 1 (work date), Joe Smith worked for the Refining Group (group) of the Engineering Department (department) of the Construction Division (division) of IT Inc. (company) on project 27 (project).
On August 1 (work date), Joe Smith worked for the Marketing Group (group) of the Sales Department (department) of the XYZ Division (division) of IT Inc. (company) on project 84 (project).
I need a form to enter these records for Joe Smith for August 1.
Thanks,
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message news:42***********************@per-qv1-newsreader-01.iinet.net.au... Tom, the question is not so much about the form, as it is about getting the data structure right.
To my way of thinking, companies, divisions, and departments are actually layers of the same kind of entity, whereas projects are a different kind of entity. A project might be shared amongst different departments or divisions, and could have a starting and ending date, whereas a department would be a (normally) permanent section of just one division and so forth up the tree.
If that is so, you might consider making a "Client" table where you can store all the first kind of entity. It will have a ClientID field as primary key, and a ParentID field that indicates the immediate parent of this client. So, if the "client" is a division type, its ParentID would be the ClientID of a record that is a company.
You would then have another table for Projects, and a table for Staff. Another table might then have fields: ClientID: foreign key to Client.ClientID (so can be a co, dept, div, ...) ProjectID: foreign key to Project.ProjectID StaffID: foreign key to Staff.StaffID WorkDate: date the work was done. Each record says something like this: on August 1 (work date), Joe Smith (staff) worked for the IT Department (client) on project 49 (whatever that is.)
If that copes with what you need, you would then have a form with 3 combos and a text box for the date. Chances are, that's not exactly what you need, but hopefully it gets you thinking in a useful direction.
"Tom" <no***@email.com> wrote in message news:rY****************@newsread1.news.atl.earthli nk.net...I am looking for some ideas for how to design the layout of the form for data entry and to display the data for the following situation: There are many sales associates. A sales associate can work for multiple companies and work for multiple divisions within each company. Within each division he can work in multiple departments and within each department he can work with multiple groups. In each group he works on multiple projects. All the work areas of each sales associates needs to be input in the form and displayed in the form - Companies, Divisions, Departments, Groups and Projects.There are one-to-many relationships between company and division, division and dpartment, department and group and group and project.
So, you have a couple of choices.
Standard structure
==============
Create:
- a table of possible Group values (records for "Industrial", etc);
- another table to hold the Department values (records for "IT", etc.)
- another table for Division values.
- another table for Companies.
- the main table that will have fields:
o GroupID
o DepartmentID
o DivisionID
o CompanyID
o StaffID
o WorkDate
The disadvantage of that approach is that you can end up choosing nonsense
combinations, such as the Welfare department of a Law form. :-)
Alternative structure
==============
The other structre suggested earlier has the disadvantage that you do have
to go through and enter each division that applies to each company, and then
each deparment of each division, and so on. While this takes more effort
initially, it may provide better data, and it copes with internal company
structures that may not match the standard one (e.g. small companies don't
have departments of divisions.)
Either way, once you have the tables in place, and the relationships between
them, you can start to think about how to create forms.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message
news:5T****************@newsread1.news.atl.earthli nk.net... Allen,
Thanks for the response!
I need records to say: On August 1 (work date), Joe Smith worked for the Industrial Group (group) of the IT Department (department) of the ABC Division (division) of IT Inc. (company) on project 49 (project).
On August 1 (work date), Joe Smith worked for the Refining Group (group) of the Engineering Department (department) of the Construction Division (division) of IT Inc. (company) on project 27 (project).
On August 1 (work date), Joe Smith worked for the Marketing Group (group) of the Sales Department (department) of the XYZ Division (division) of IT Inc. (company) on project 84 (project).
I need a form to enter these records for Joe Smith for August 1.
Thanks,
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message news:42***********************@per-qv1-newsreader-01.iinet.net.au... Tom, the question is not so much about the form, as it is about getting the data structure right.
To my way of thinking, companies, divisions, and departments are actually layers of the same kind of entity, whereas projects are a different kind of entity. A project might be shared amongst different departments or divisions, and could have a starting and ending date, whereas a department would be a (normally) permanent section of just one division and so forth up the tree.
If that is so, you might consider making a "Client" table where you can store all the first kind of entity. It will have a ClientID field as primary key, and a ParentID field that indicates the immediate parent of this client. So, if the "client" is a division type, its ParentID would be the ClientID of a record that is a company.
You would then have another table for Projects, and a table for Staff. Another table might then have fields: ClientID: foreign key to Client.ClientID (so can be a co, dept, div, ...) ProjectID: foreign key to Project.ProjectID StaffID: foreign key to Staff.StaffID WorkDate: date the work was done. Each record says something like this: on August 1 (work date), Joe Smith (staff) worked for the IT Department (client) on project 49 (whatever that is.)
If that copes with what you need, you would then have a form with 3 combos and a text box for the date. Chances are, that's not exactly what you need, but hopefully it gets you thinking in a useful direction.
"Tom" <no***@email.com> wrote in message news:rY****************@newsread1.news.atl.earthli nk.net...I am looking for some ideas for how to design the layout of the form for data entry and to display the data for the following situation: There are many sales associates. A sales associate can work for multiple companies and work for multiple divisions within each company. Within each division he can work in multiple departments and within each department he can work with multiple groups. In each group he works on multiple projects. All the work areas of each sales associates needs to be input in the form and displayed in the form - Companies, Divisions, Departments, Groups and Projects.There are one-to-many relationships between company and division, division and dpartment, department and group and group and project.
I have the standard table structure and now I'm looking for ideas for a
user-friendly form.
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:42***********************@per-qv1-newsreader-01.iinet.net.au... So, you have a couple of choices.
Standard structure ============== Create: - a table of possible Group values (records for "Industrial", etc); - another table to hold the Department values (records for "IT", etc.) - another table for Division values. - another table for Companies. - the main table that will have fields: o GroupID o DepartmentID o DivisionID o CompanyID o StaffID o WorkDate
The disadvantage of that approach is that you can end up choosing nonsense combinations, such as the Welfare department of a Law form. :-)
Alternative structure ============== The other structre suggested earlier has the disadvantage that you do have to go through and enter each division that applies to each company, and then each deparment of each division, and so on. While this takes more effort initially, it may provide better data, and it copes with internal company structures that may not match the standard one (e.g. small companies don't have departments of divisions.)
Either way, once you have the tables in place, and the relationships between them, you can start to think about how to create forms.
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message news:5T****************@newsread1.news.atl.earthli nk.net... Allen,
Thanks for the response!
I need records to say: On August 1 (work date), Joe Smith worked for the Industrial Group (group) of the IT Department (department) of the ABC Division (division) of IT Inc. (company) on project 49 (project).
On August 1 (work date), Joe Smith worked for the Refining Group (group) of the Engineering Department (department) of the Construction Division (division) of IT Inc. (company) on project 27 (project).
On August 1 (work date), Joe Smith worked for the Marketing Group (group) of the Sales Department (department) of the XYZ Division (division) of IT Inc. (company) on project 84 (project).
I need a form to enter these records for Joe Smith for August 1.
Thanks,
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message news:42***********************@per-qv1-newsreader-01.iinet.net.au... Tom, the question is not so much about the form, as it is about getting the data structure right.
To my way of thinking, companies, divisions, and departments are actually layers of the same kind of entity, whereas projects are a different kind of entity. A project might be shared amongst different departments or divisions, and could have a starting and ending date, whereas a department would be a (normally) permanent section of just one division and so forth up the tree.
If that is so, you might consider making a "Client" table where you can store all the first kind of entity. It will have a ClientID field as primary key, and a ParentID field that indicates the immediate parent of this client. So, if the "client" is a division type, its ParentID would be the ClientID of a record that is a company.
You would then have another table for Projects, and a table for Staff. Another table might then have fields: ClientID: foreign key to Client.ClientID (so can be a co, dept, div, ...) ProjectID: foreign key to Project.ProjectID StaffID: foreign key to Staff.StaffID WorkDate: date the work was done. Each record says something like this: on August 1 (work date), Joe Smith (staff) worked for the IT Department (client) on project 49 (whatever that is.)
If that copes with what you need, you would then have a form with 3 combos and a text box for the date. Chances are, that's not exactly what you need, but hopefully it gets you thinking in a useful direction.
"Tom" <no***@email.com> wrote in message news:rY****************@newsread1.news.atl.earthli nk.net... I am looking for some ideas for how to design the layout of the form for data entry and to display the data for the following situation: There are many sales associates. A sales associate can work for multiple companies and work for multiple divisions within each company. Within each division he can work in multiple departments and within each department he can work with multiple groups. In each group he works on multiple projects. All the work areas of each sales associates needs to be input in the form and displayed in the form - Companies, Divisions, Departments, Groups and Projects.There are one-to-many relationships between company and division, division and dpartment, department and group and group and project.
I have the standard table structure and now I'm looking for ideas for a
user-friendly form.
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:42***********************@per-qv1-newsreader-01.iinet.net.au... So, you have a couple of choices.
Standard structure ============== Create: - a table of possible Group values (records for "Industrial", etc); - another table to hold the Department values (records for "IT", etc.) - another table for Division values. - another table for Companies. - the main table that will have fields: o GroupID o DepartmentID o DivisionID o CompanyID o StaffID o WorkDate
The disadvantage of that approach is that you can end up choosing nonsense combinations, such as the Welfare department of a Law form. :-)
Alternative structure ============== The other structre suggested earlier has the disadvantage that you do have to go through and enter each division that applies to each company, and then each deparment of each division, and so on. While this takes more effort initially, it may provide better data, and it copes with internal company structures that may not match the standard one (e.g. small companies don't have departments of divisions.)
Either way, once you have the tables in place, and the relationships between them, you can start to think about how to create forms.
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message news:5T****************@newsread1.news.atl.earthli nk.net... Allen,
Thanks for the response!
I need records to say: On August 1 (work date), Joe Smith worked for the Industrial Group (group) of the IT Department (department) of the ABC Division (division) of IT Inc. (company) on project 49 (project).
On August 1 (work date), Joe Smith worked for the Refining Group (group) of the Engineering Department (department) of the Construction Division (division) of IT Inc. (company) on project 27 (project).
On August 1 (work date), Joe Smith worked for the Marketing Group (group) of the Sales Department (department) of the XYZ Division (division) of IT Inc. (company) on project 84 (project).
I need a form to enter these records for Joe Smith for August 1.
Thanks,
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message news:42***********************@per-qv1-newsreader-01.iinet.net.au... Tom, the question is not so much about the form, as it is about getting the data structure right.
To my way of thinking, companies, divisions, and departments are actually layers of the same kind of entity, whereas projects are a different kind of entity. A project might be shared amongst different departments or divisions, and could have a starting and ending date, whereas a department would be a (normally) permanent section of just one division and so forth up the tree.
If that is so, you might consider making a "Client" table where you can store all the first kind of entity. It will have a ClientID field as primary key, and a ParentID field that indicates the immediate parent of this client. So, if the "client" is a division type, its ParentID would be the ClientID of a record that is a company.
You would then have another table for Projects, and a table for Staff. Another table might then have fields: ClientID: foreign key to Client.ClientID (so can be a co, dept, div, ...) ProjectID: foreign key to Project.ProjectID StaffID: foreign key to Staff.StaffID WorkDate: date the work was done. Each record says something like this: on August 1 (work date), Joe Smith (staff) worked for the IT Department (client) on project 49 (whatever that is.)
If that copes with what you need, you would then have a form with 3 combos and a text box for the date. Chances are, that's not exactly what you need, but hopefully it gets you thinking in a useful direction.
"Tom" <no***@email.com> wrote in message news:rY****************@newsread1.news.atl.earthli nk.net... I am looking for some ideas for how to design the layout of the form for data entry and to display the data for the following situation: There are many sales associates. A sales associate can work for multiple companies and work for multiple divisions within each company. Within each division he can work in multiple departments and within each department he can work with multiple groups. In each group he works on multiple projects. All the work areas of each sales associates needs to be input in the form and displayed in the form - Companies, Divisions, Departments, Groups and Projects.There are one-to-many relationships between company and division, division and dpartment, department and group and group and project.
The usual form would be a bunch of combos--one each for GroupID, the
DepartmentID, etc--and a text box to enter the date.
Each combo have a lookup table as the RowSource.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message
news:%L**************@newsread2.news.atl.earthlink .net... I have the standard table structure and now I'm looking for ideas for a user-friendly form.
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message news:42***********************@per-qv1-newsreader-01.iinet.net.au... So, you have a couple of choices.
Standard structure ============== Create: - a table of possible Group values (records for "Industrial", etc); - another table to hold the Department values (records for "IT", etc.) - another table for Division values. - another table for Companies. - the main table that will have fields: o GroupID o DepartmentID o DivisionID o CompanyID o StaffID o WorkDate
The disadvantage of that approach is that you can end up choosing nonsense combinations, such as the Welfare department of a Law form. :-)
Alternative structure ============== The other structre suggested earlier has the disadvantage that you do have to go through and enter each division that applies to each company, and then each deparment of each division, and so on. While this takes more effort initially, it may provide better data, and it copes with internal company structures that may not match the standard one (e.g. small companies don't have departments of divisions.)
Either way, once you have the tables in place, and the relationships between them, you can start to think about how to create forms.
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message news:5T****************@newsread1.news.atl.earthli nk.net... Allen,
Thanks for the response!
I need records to say: On August 1 (work date), Joe Smith worked for the Industrial Group (group) of the IT Department (department) of the ABC Division (division) of IT Inc. (company) on project 49 (project).
On August 1 (work date), Joe Smith worked for the Refining Group (group) of the Engineering Department (department) of the Construction Division (division) of IT Inc. (company) on project 27 (project).
On August 1 (work date), Joe Smith worked for the Marketing Group (group) of the Sales Department (department) of the XYZ Division (division) of IT Inc. (company) on project 84 (project).
I need a form to enter these records for Joe Smith for August 1.
Thanks,
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message news:42***********************@per-qv1-newsreader-01.iinet.net.au... Tom, the question is not so much about the form, as it is about getting the data structure right.
To my way of thinking, companies, divisions, and departments are actually layers of the same kind of entity, whereas projects are a different kind of entity. A project might be shared amongst different departments or divisions, and could have a starting and ending date, whereas a department would be a (normally) permanent section of just one division and so forth up the tree.
If that is so, you might consider making a "Client" table where you can store all the first kind of entity. It will have a ClientID field as primary key, and a ParentID field that indicates the immediate parent of this client. So, if the "client" is a division type, its ParentID would be the ClientID of a record that is a company.
You would then have another table for Projects, and a table for Staff. Another table might then have fields: ClientID: foreign key to Client.ClientID (so can be a co, dept, div, ...) ProjectID: foreign key to Project.ProjectID StaffID: foreign key to Staff.StaffID WorkDate: date the work was done. Each record says something like this: on August 1 (work date), Joe Smith (staff) worked for the IT Department (client) on project 49 (whatever that is.)
If that copes with what you need, you would then have a form with 3 combos and a text box for the date. Chances are, that's not exactly what you need, but hopefully it gets you thinking in a useful direction.
"Tom" <no***@email.com> wrote in message news:rY****************@newsread1.news.atl.earthli nk.net... >I am looking for some ideas for how to design the layout of the form >for data entry and to display the data for the following situation: > There are many sales associates. A sales associate can work for > multiple companies and work for multiple divisions within each > company. Within each division he can work in multiple departments and > within each department he can work with multiple groups. In each group > he works on multiple projects. All the work areas of each sales > associates needs to be input in the form and displayed in the form - > Companies, Divisions, Departments, Groups and Projects.There are > one-to-many relationships between company and division, division and > dpartment, department and group and group and project.
The usual form would be a bunch of combos--one each for GroupID, the
DepartmentID, etc--and a text box to enter the date.
Each combo have a lookup table as the RowSource.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message
news:%L**************@newsread2.news.atl.earthlink .net... I have the standard table structure and now I'm looking for ideas for a user-friendly form.
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message news:42***********************@per-qv1-newsreader-01.iinet.net.au... So, you have a couple of choices.
Standard structure ============== Create: - a table of possible Group values (records for "Industrial", etc); - another table to hold the Department values (records for "IT", etc.) - another table for Division values. - another table for Companies. - the main table that will have fields: o GroupID o DepartmentID o DivisionID o CompanyID o StaffID o WorkDate
The disadvantage of that approach is that you can end up choosing nonsense combinations, such as the Welfare department of a Law form. :-)
Alternative structure ============== The other structre suggested earlier has the disadvantage that you do have to go through and enter each division that applies to each company, and then each deparment of each division, and so on. While this takes more effort initially, it may provide better data, and it copes with internal company structures that may not match the standard one (e.g. small companies don't have departments of divisions.)
Either way, once you have the tables in place, and the relationships between them, you can start to think about how to create forms.
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
"Tom" <no***@email.com> wrote in message news:5T****************@newsread1.news.atl.earthli nk.net... Allen,
Thanks for the response!
I need records to say: On August 1 (work date), Joe Smith worked for the Industrial Group (group) of the IT Department (department) of the ABC Division (division) of IT Inc. (company) on project 49 (project).
On August 1 (work date), Joe Smith worked for the Refining Group (group) of the Engineering Department (department) of the Construction Division (division) of IT Inc. (company) on project 27 (project).
On August 1 (work date), Joe Smith worked for the Marketing Group (group) of the Sales Department (department) of the XYZ Division (division) of IT Inc. (company) on project 84 (project).
I need a form to enter these records for Joe Smith for August 1.
Thanks,
Tom
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message news:42***********************@per-qv1-newsreader-01.iinet.net.au... Tom, the question is not so much about the form, as it is about getting the data structure right.
To my way of thinking, companies, divisions, and departments are actually layers of the same kind of entity, whereas projects are a different kind of entity. A project might be shared amongst different departments or divisions, and could have a starting and ending date, whereas a department would be a (normally) permanent section of just one division and so forth up the tree.
If that is so, you might consider making a "Client" table where you can store all the first kind of entity. It will have a ClientID field as primary key, and a ParentID field that indicates the immediate parent of this client. So, if the "client" is a division type, its ParentID would be the ClientID of a record that is a company.
You would then have another table for Projects, and a table for Staff. Another table might then have fields: ClientID: foreign key to Client.ClientID (so can be a co, dept, div, ...) ProjectID: foreign key to Project.ProjectID StaffID: foreign key to Staff.StaffID WorkDate: date the work was done. Each record says something like this: on August 1 (work date), Joe Smith (staff) worked for the IT Department (client) on project 49 (whatever that is.)
If that copes with what you need, you would then have a form with 3 combos and a text box for the date. Chances are, that's not exactly what you need, but hopefully it gets you thinking in a useful direction.
"Tom" <no***@email.com> wrote in message news:rY****************@newsread1.news.atl.earthli nk.net... >I am looking for some ideas for how to design the layout of the form >for data entry and to display the data for the following situation: > There are many sales associates. A sales associate can work for > multiple companies and work for multiple divisions within each > company. Within each division he can work in multiple departments and > within each department he can work with multiple groups. In each group > he works on multiple projects. All the work areas of each sales > associates needs to be input in the form and displayed in the form - > Companies, Divisions, Departments, Groups and Projects.There are > one-to-many relationships between company and division, division and > dpartment, department and group and group and project.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Peter |
last post by:
For some unknown reason my Form Layout Window has stopped showing a form on
it.
I can open & close the window, set docking on/off but no form. The right
click start-up options are also greyed out....
|
by: Usenet User |
last post by:
A user informed me that some pages I've created with nested tables are
spewing out dozens of blank pages at the end of a print run. No one
noticed this for a long time, as printer-friendly files...
|
by: Mike |
last post by:
Hey guys I am pulling my hair out on this problem!!!!! Any help or ideas or
comments on how to make this work I would be grateful! I have been working
on this for the past 4 days and nothing I do...
|
by: Tom |
last post by:
I am looking for some ideas for how to design the layout of the form for
data entry and to display the data for the following situation:
There are many sales associates. A sales associate can work...
|
by: Steve Richter |
last post by:
I am spending too much time thinking of nesting tables within tables to
get the form layout that I want.
a simple example:
Sub heading:
property text: entry field
property text: entry...
|
by: Luke |
last post by:
Hi.
I am trying to make correct layout, here is an example of (dynamically
generated content via jsp):
http://localhost/www/layout.htm
Most outer div is positioned absolute (if not then it...
|
by: Samuel Shulman |
last post by:
I am looking for good guidance for positioning controls on the
form.document, it is absolute nightmare and I don't know where to begin
Thank you,
Samuel Shulman
|
by: Brian Tkatch |
last post by:
Not sure if this is the way it's supposed to be, but after a Layout
event on an MDI form, the form's new width is set, but the MDIClient's
width is not.
As an example, start a new Windows...
|
by: dlogan |
last post by:
Since this is becoming a complete hack-job, I think its about time I asked for some help. I am trying to make a calendar using AJAX to allow for the main calendar to display, then load in the events...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |