 |
stickleprojects Level: Moderator

 Registered: 09-09-2002 Posts: 891
|
Re: Too Many Tables
Hi,
Without seeing the forms, one thing occurs.
Are there 84 individual fields, or are any related to each other?
Example:
A printed invoice has, say about 15 fields at the top (for the client name, address, etc.) and about 30 rows for items - with 3 columns per row for desc, qty, price.
That is actually:
1 field for the client (the rest is looked-up from the client table)
a couple of fields to identify the invoice (date, ref, notes, etc.)
another table containing the invoiceid, desc, qty and price.
So can you "group" the fields on a form?
Hope this is clear,
Kieron
PS. If you can get a scan/screen-dump/sample up here that would be really helpful.
____________________________
Build it better, faster, quicker, easier.. then fix it (non-offical MS mission statement)
|
|
16-02-2006 at 05:53 PM |
|
|
bolendercm Level: Scholar

 Registered: 25-10-2005 Posts: 39
|
Re: Too Many Tables
Kieron,
Thanks for the reply.
There is information common to every form: Date, Type(Critical, Sub Critical or Non-Critical), Crew Size, Frequency(Yearly, Quarterly, Monthly or Weekly), Hours and Cost Center.
Of the over 150 Maint Sheets they are divided into three maintenance areas, HVAC, Electrical and Power Production.
I could group fields on the form. Do you mean sub forms on a Main form?
The top of the form has your normal info. FY, Cost Center
Description, Frequency.
The Mid section section has Required Actions, Reference, Hours and Crew size.
The bottom section has Date, Initials and Total number of hours.
It just occured to me . I could have Main form and the Mid and Bottom sections could be a sub-forms.
The only problem with that is, the largest section is the 10 Required Maintenance Action fields located in the mid section and each one is different per piece of equipment.
Am I on the right track?
____________________________
C.......................
|
|
16-02-2006 at 06:15 PM |
|
|
JLRodgers Level: Moderator
 Registered: 04-04-2002 Posts: 1619
|
Re: Too Many Tables
When you look at the data, try to find things that are similar to all, that could be listed in the same table (think of a table from a programming point of view, not a user POV).
Meaning that if you look at a record for say a part, you could have one table that has:
ID (primary key, unique), part #, date, type, freq, etc
then other tables for information that's unique to each form
ex: LID (lid = the ID in the other table that it applies to), extruder, press
(actually I find it hard to think of things... technically, you could just have one large table with all the fields, but only enter data if it's relevant to the field - otherwise keep it null or "" )
Anyway, then you could just, when a person wants info, use the first table with all the common info or the other table, and use a query to find the related records in the other table(s) based on the id.
____________________________
Everywhere's Local (classifieds, job postings, & more for everycity in the world - user entered)
|
|
16-02-2006 at 11:19 PM |
|
|
|
|
 |
 |