Construction Industry

[timm2985]

Good morning,

This is my first post on this forum and I am new to the program. I have some experience with Access and have a pretty good grasp on how the program works.

I am trying to create a database that effectively tracks our construction operations.

I want to present the main goals below:

1) I have to track 3 main categories: Equipment, Employees, and Materials.

2) I want to be able to have a SINGLE costing input screen. I want to be able to have a button/pull-down option that lets me chose between the three main categories mentioned above (Equipment, Employees, or Materials). I know HOW to create the said button or pull-down menu, however, I want this button to alter the other inputs after choosing one of the above options.

3) After choosing one of the above options from the menu, I want the database to automatically fill in the appropriate rate for the piece of equipment or employee (if the material option is chosen, this would obviously not be applicable).

Any input or help would be much appreciated.

Thanks in advance!

[Fenton]

The single costing screen would belong to a "Project" (or "Job"), which would be a table. I'm a bit surprised you did not include this, as it is the central table of such a solution. You'd also need a "Client" (or "Customer") table also.

The 3 categories you mentioned would also be tables. However, each one would have its OWN table, as well as "equipment used on job", "employees working on job", "materials used on job."

The "own" tables would be Equipment, Employees, Materials. These would function as "reference" tables, to store the data for each "entity." Price/rate would be in those tables.* Each would have a unique auto-enter, non-modifiable (in most circumstances) Primary ID.

That is what you would enter into the "used on job" tables. The "price/rate" data would be Looked Up (or auto-enter by calculation) by entering the relevant entity's ID as a foreign key.

This is more or less standard for relational design, no matter what application you're using. But the terms used and implementation would likely be somewhat different.

As far as interface, you could put "portals" (a little window into another table, or itself, via a relationship) on the Job layout. Each could be within its own Tab, in a Tab Object; so there would be plenty of room for each, if needed.

Portal rows are capable of creating new related records, if that option is on in the relationship. Choosing the item could be via a drop down Value List (tho that can be awkward if the list is very long).

That's kind of the basics, and you know some of it. So good luck, and ask more questions as you go.

*Price/rate date would originally come from its entity's table, looked up into the relevant "entity per job" table. It would then often be editable, if needed. In any case, you need to think ahead, about such things as deletion of the original entity, and what data needs to still remain in the "per job" tables. This is called "redundant data," but is often required. How many redundant fields are looked up is always a question.

Edited March 22, 2010 by Guest

[timm2985]

Hi Fenton,

Wow! Thank you very very much for the in-depth and fast response. I will attempt to create these data tables and relationships and ask more questions once I run into any problems.

Again, I greatly appreciate your input and know-how!

-Tim

[timm2985]

Hi Fenton,

I tried to implement your suggestions, however, I am having an extremely tough time. Is there any way you could put your suggestions into a visual version instead? I am a little confused as to the 'OWN' tables and the 'job' tables.

Thank you ahead of time!

Sincerely,

Tim

[Fenton]

Tables:

Clients

Jobs

Job Material Items

Job Equipment Items

Job Employee Items

Materials

Equipment

Employees

One has to consider at this point about the "job items" tables; whether:

1. It could be as above, 3 tables.

2. "Job items" could be only 1 table, with the fields required for each kind of item. Or,

3. It would be actually 4 tables, with a central "Job Items" table, then 1-to-1 relationships to "Job Items Equip", "Job Items Material", "Job Items Employees"

Probably #2 above is the easist.

#1 above has merit, but it becomes very unweildy if you ever want to tie more subtables to them later.

#3 is in some ways a bit more setup, and a little more to think about, but it has more flexibility. I don't know if I'd use in this case or not (not much help there, am I?).

[fhornberger]

What is the job description for a Construction Project Manager?

Function: To manage construction projects from the beginning to end resulting in successful and timely project completion. Responsibilities: Participate in cost estimates, Establish budget and project schedule, Review and monitor all design and/or construction documents for conformance with budget and schedule, Negotiate, award and write subcontracts and material purchases, Initiate and obtain permits, insurance and bond requirements prior to construction, Monitor and control all change orders, RFIs and submittals, Conduct daily and weekly meetings with staff and owners/clients, Monitor superintendents on monthly schedule and safety requirements, Prepare reports and forecasts for owners and assist in developing new business including presentations. Requirements: Engineering/Contruction Management degree or equivalent experience, Leadership and problem solving ability, Strong sense of urgency, Good organizational, communication and computer skills.

From:

Frederick Hornberger

CEO of Hornberger Management Company, senior construction recruiter for executives regarding construction jobs, and construction resumes.

http://www.hmc.com

http://www.constructionexecutive.com