How should these sheets be imported

WetCoast

New member
Local time
Today, 15:25
Joined
Nov 18, 2009
Messages
9
I have attached an excel2007 workbook containing the 3 sheets that I would like to import into access2007.

The tables are for a maintenance database I am working on. The tables attached are part of the VMRS (Vehicle Maintenance Records System).

I need to be able to import the tables in such a manner that I am able to use the 3 level code on a form:

I have tried importing the information in various arrangements, but am unable to make the appropriate relationships, combo boxes etc.

Out of the 82 tables that comprise this system, these 3 are making me crazy! :eek:

thanks for taking the time to read this.
 

Attachments

Last edited:
The spreadsheet looks straightforward. You would not import COMPCODE9D as it is derived from the other columns.

When you wish to display the combined code, concatenate the fields.
The control source would be:
= SYS & "-" & ASY & "-" COMP

However with 82 tables in your database it is very unlikely to have been optimally designed.
This impression is supported by the statement that you are having trouble with relationships and combos.

Either that or it is a necessarily very complex design.
However in this case I expect you probably would not be asking this question.
 
The spreadsheet looks straightforward. You would not import COMPCODE9D as it is derived from the other columns. (Did you look at all 4 sheets or just the component code?)

Yes... I guess it is 'straight forward' to most... but not to me yet! (Which is why I am asking for help... haven't you ever been stuck on something you just can't get your head around?)

When you wish to display the combined code, concatenate the fields.
The control source would be:
= SYS & "-" & ASY & "-" COMP

Will this allow the use of combo boxes? (Still trying to wrap my head around concatenating, haven't found anything in my searches this morning to 'trigger the event' ;)!)
What I want to happen is that the choice of system limits the assemblies shown, and the choice of the listed assemblies then limits the 21000+ choices to the components that are found in the chosen system/assembly.

However with 82 tables in your database it is very unlikely to have been optimally designed.

:eek: It will most likely have upwards of 200 by the time it's finished.... I shouldn't be doing this in Access???

This impression is supported by the statement that you are having trouble with relationships and combos.

Yes, being self taught does have those drawbacks. I am an unwilling retiree truck driver (medical reasons), living in a small isolated community, trying to come up with a small business that will enable National Safety Code compliance for small trucking outfits... a big part of that is records... being able to prove due diligence. I have been working on this , on and off, (in a vacuum) since 2007.
I have been encouraged by the amount of information that is available on Access when using Google search (one of the reasons I choose Access) and searching various forums has helped me through most stumbling blocks.. but this one I just can't wrap my head around, and I haven't been able to find an example that I can relate to to help me work this out... which is why I posted the question...


Either that or it is a necessarily very complex design.

Yes, in a way... but think of the 82 VMRS tables as lists to choose from and I don't find it as scary! :D

However in this case I expect you probably would not be asking this question.

Well if I don't know... and I don't ask.... how will I get pass this?

Galaxiom
, thanks for taking the time to read and respond to my issue.

However I don't feel much farther ahead than I did when I posted my question... if anything I feel a little further behind and a lot more intimidated.

PS: I have attached a pic of a rough form to give an idea of the direction I'm going. (I haven't created any forms for this database yet as I haven't been able to figure out how to relate the attached sheets from my first post.) if there is anyone interested in helping me walk through this. My end goal is to have accurate reports, by system, assembly and component in various detail.
 

Attachments

  • VMRS-WorkOrder.jpg
    VMRS-WorkOrder.jpg
    41.6 KB · Views: 289
Looking at your layout, you have far too many tables. You need to rethink your assemblies and components as you appear to have an individual table for each component and assembly details
 
16:31
I think the main reason I am having a hard time is the examples that are out there are dealing with two or more separate tables. ie:the Category and Product combo box. If I only import the CodeKey33 spreadsheet, the info is in one table.... can relationships be created between columns and enable the data to be manipulated the way I would like? At this point I am so dazed and confused by the volume of information that is out there I don't dare try to wrap my head around the concatenating that Galaxiom suggested in the earlier post without a little more understanding.

If I import all 3 sheets, Code key 31, codekey32 and code key 33, how then do I relate the resulting tables. and there there is that little bit about the "group" code X0X where the middle digit identifies the group.

The bottom line... I am willing to pay for this help. I have a paypal account (or we can work out another method for payment delivery.)... lets work out a deal... maybe it could be an on going tutoring/ mentoring setup. I need help, which is why I am here to begin with. I do want to create this database, as it is the basis of my small business plan.


The attached excel workbook is showing how I received (some) the files from the ATA when I purchased the coding convention.

I would like to be able to import the tables from the excel file into access, in such a manner that I can create the appropriate relationships for the combo boxes to be able to act in the manner I described in my post above.

Do I import all 3 sheets, do I only import the components spread sheet? What columns of which sheet(s) should be imported. Once imported, how do I create the relationships that will let me use the info correctly in combo boxes, giving the level of detail wanted for reports??

Can this be done? If yes, would someone please be so kind as to walk me through how? For whatever reason I cannot reason or logic my way through this.... maybe it's because what I want to do can not be done!!:eek:


I did not design the VMR system.
I am attempting to incorporate the system into my database.
It was developed by the American Trucking Associations' Technology & Maintenance Council. (In my understanding 'normalized' to the nth degree)

A Structured Coding System
VMRS is a structured coding system, providing the discipline necessary to operate in
today's computer-based information age or — where desired — as a completely manual
system. Simple in concept, VMRS can be used at any level, from total operating systems
down to the individual part level. The level of coding used is entirely up to the user.
One can modify the coding level at any time without the need to redesign the coding
structure or implement costly new programs. No matter which level the user selects, the
data collected can be compared directly to data collected by others at the same or higher
VMRS coding level.

The coding structure encompasses most equipment found within today's transportation
activities including trucks, tractors, trailers, forklifts, shop equipment, off-road vehicles,
utility vehicles, etc.


Does the System Do the Following?

  • [*]Use the VMRS Vehicle Master Record.
    [*]Identify Equipment Vocation -- Code Key 1.
    [*]Segregate costs by Reason for Repair -- Code Key 14
    [*]Identify work accomplished using VMRS Coding -- Code Key 15
    [*]At minimum, identify systems via the three-digit VMRS System Code -- Code Key 31
    [*]For more detail, identify assemblies via the three-digit VMRS Assembly Code -- Code Key 32
    [*]For more detail, identify individual parts via the three-digit VMRS Component Code -- Code Key 33.
    [*]Identify part/vehicle manufacturers, suppliers or brands universally using -- Code Key 34.
    [*]Have the capability to record VMRS Technician Part Failure Codes -- Code Key 18.
VMRS System Level Codes
Code Key 31

VMRS 2000 uses a series of three-digit descriptor codes that readily and consistently
identify the specific systems involved. While these codes are the heart of the "common
language" of VMRS and are a vital part of the VMRS concept, they are by themselves
nothing more than coding conventions designed for use at all levels within the industry,
from fleets to mechanics to manufacturers to suppliers of parts. For example, brakes are
identified as a system by system code 013.


Assembly Level Codes
Code Key 32

Through the use of assembly level codes, VMRS provides additional capability to
further define Code Key 31's System Codes. The first classification below the system
level is referred to as the assembly. At this level, all major groupings within each system
are broken out and reported through the use of a three digit code. These, when used
with their system prefix, identify the specific assembly within a vehicle. For example,
front brakes and drums can be identified by a combination of the System and Assembly
Code 013-001.

Component Level Codes
Code Key 33

In order to provide a common generic term for each part within a vehicle, the system
and assembly codes are further subdivided to the component level. This is
accomplished through the use of an additional three digit part identifier code. These
codes should not be confused with the manufacturers' or suppliers' unique
identification (part) numbers, but rather should be considered universal identifiers or
generic terms for the part. For example, a front brake lining can be identified by the
following combination of System/Assembly/Component codes—013-001-015.

*(More info can be found in the link in my first post or here http://www.truckrealm.com/vmrs.htm )
 
Last edited:

What I want to happen is that the choice of system limits the assemblies shown, and the choice of the listed assemblies then limits the 21000+ choices to the components that are found in the chosen system/assembly.


Properly structured the combo row source population will be simple. Read about cascading comboboxes.


:eek: It will most likely have upwards of 200 [tables] by the time it's finished

A good design does not add tables and fields to extend features. It adds records. When a new specification arrives you don't want to be adding more tables.


.... I shouldn't be doing this in Access???

Access can do it but you need to restructure with less tables. There is nothing intrinsically "against the rules" about a lot of tables but it means a lot of specific form design and coding. A structure with less tables allows the forms and reports to use the same coding and in may case the same form object for multiple purposes.


I am an unwilling retiree truck driver (medical reasons), living in a small isolated community, trying to come up with a small business that will enable National Safety Code compliance for small trucking outfits

You have an advantage in that you actually understand what the database actually represents.:D


.....but think of the 82 VMRS tables as lists to choose from and I don't find it as scary! :D

You have collected data on spreadsheets. Now you must transform those tables into a database table structure. Despite appearances this is very different from speadsheets.



However I don't feel much farther ahead than I did when I posted my question... if anything I feel a little further behind and a lot more intimidated.

You have made a big step forward by coming here before spend too much time a a structure that will quickly run you into difficulty. With good structure the form and report design is very easy.

Otherwise you woud have been here in a couple of weeks asking how to automatically add fields to tables and have queries that can use variable table and field names.

Please explain more about the structure of the other tables. These will most likely combine into a very small number. Do they have a lot of fields in common?
 
Please explain more about the structure of the other tables. These will most likely combine into a very small number. Do they have a lot of fields in common?

Being that a picture is worth a 1000 words... I have attached a pic of the relationship view from access with the tables placed on it to give you an idea of what I am talking about( without relationships)... ps it turns out there are 'only' 44 tables. Some code keys are no longer used or are reserved for future use.

There are also instructions sets explaining how the codes are used: (Here are a few to give you an idea.)

0mvmrsdbtablesj
vmrsdbtables.jpg
ENGINE TYPE CODE
Characters 1-5 are the VMRS Mfr Code. from Code Key 34

Characters 6-7 are Engine Configuration codes from Code Key 35
Character 8 is the code for horsepower range from
Code Key 6
Chacacter 9 is the code for power source (fuel) from Code Key 5.

TRANSMISSION CONFIGURATION CODE
Characters 1-5 are the VMRS Mfr Code. from Code Key 34

Character 6 is the code for transmission speeds from Code Key 7

Character 7 is the code for number of forward speeds from Code Key 8
Character 8 is the actual number of reverse speeds, not a VMRS Code Key.

Character 9 is the code for PTO status from Code Key 36.


SPECIAL BODY TYPE CODE
Characters 1-5 are the VMRS Mfr Code. from Code Key 34

Character 6 is the code for body material from Code Key 47

Characters 7-9 are the code for special body type from Code Key 48


vmrsdbta
This is the "base" of the the database. I am working in/on another database for Drivers, Hours of Service, etc. Eventually I do want this be accessible from the web.... The fact that I have been unemployed for quite sometime means I am working on a zero budget for R&D. ;) It might not be the best way, but at this point in time, for me, it is what I can afford.

So... am I out to lunch? Can anyone besides me see the value in this type of record keeping? At this point I'm thinking that everything I was thinking is wrong!:eek:

Galaxiom... thank you for your continued support! :D




vmrsdbta
 

Attachments

  • VMRS-DB-Tables.jpg
    VMRS-DB-Tables.jpg
    72.9 KB · Views: 588
I think your table structure should look like this (attached)
 

Attachments

It is a lot to take in but it would appear many of your tables have two natural data fields, a code value and some kind of value. Many of these tables which hold attributes of a truch could be place in a single table.

There is essentially no difference between a CK20 and a CK25 code. It is a number or a string of text that could be recorded in a single table regardless of the type of code. Another table holds the name of the code and the forms are designed to use the appropriate label for the type code heading. But the value itseld is no different from the other table.

The attribute that is currently expressed as the basis for a table is stored as a field in the combined table. These are stored as IDs related to another table which holds the actual names of what are currently tables. I'm not sure how many of your tables could be combined like this.

Sorry I can't be clearer about this. Try to comprehend the concept of expressing the attribute that is currently the basis for table as a field in the combined table.

When using combos the single table provides the row source for all combos. The Where clause of the Row source is modified to be sensitive to the values selected in other combos.

The metric equivalent should not be stored in a table. Since you have the imperial dimension the metric should be calculated when required using a formula. Storing both in a table is a breach of normalisation since the values could contradict.
 
GalaxiomAtHome

sorry for the delay... full house this weekend...

Thank you for your response....


You've definitely given me some things to think on! Much appreciated! I've been in a vacuum so long it is hard to see any other way on my own. Your insight is welcome...



T
he metric equivalent should not be stored in a table. Since you have the imperial dimension the metric should be calculated when required using a formula. Storing both in a table is a breach of normalisation since the values could contradict.

Yes I am aware of this. It's a visual reminder to use metric when setting up the table. (Canadian) I believe there a a couple of other tables like this. (I tend to use a lot of visual aids!;))


well... back to the drawing board, any other help, critiques, etc welcome..

thanks again for taking the time to read this :)
 
COMPCODE9D as it is derived from the other columns.

When you wish to display the combined code, concatenate the fields.
The control source would be:
= SYS & "-" & ASY & "-" COMP


So, I have three fields (numeric) formatted as 000 and show up in queries as 001,010 025. When using SYS & "-" & ASY & "-" COMP , the leading 0's are removed and it shows up as 1-10-25. What's the trick to retain the 3 characters??
 
Format([SYS],"000") & "-" & Format([ASY],"000") & "-" & Format([COMP],"000")
 
Last edited:
Back here from the other thread eventually. Sorry for the delay.
http://www.access-programmers.co.uk/forums/showthread.php?t=184062

I do believe the table structure you posted there is what you need. However you can drop the CodeKeyID autonumber since you already have a natural key in your CodeKey field.

So when you choose the CodeKeyNumber in the first combo the second combo offers all the CodeKeyCodes and Descriptions matching the selected code key.

Using a Union query in the Row Source of the CodeKeyDescription combo will allow either the CodeKeyCode or the CodeDescription to be entered or selected. This will then accomodate entry by users who know the codes really well and those who need the description. I am fairly sure this technique has been described in detial on this site before.

You might even consider including a toggle near the combo to change the display sorting between CodeKeyCode and CodeDescription first.

A textbox with a search function to locate a string anywhere in the description would also be a very good idea. eg show descriptions including "refrigerated". This would also be incorporated in the RowSource query to limit the combo to those matching the search.

In fact it might be a good idea to make the search input a combo whose row source maintains a list of recent searches. Include a button to clear the search so the user doesn't have to backspace it away.

Hope this makes sense.
 

Users who are viewing this thread

Back
Top Bottom