I am beginning to wonder if i overcomplicate my database. i am going to add a
field to my T_partnumbers for unit of measure (UOM) and can not decide if i
should do it like i have in the past and use a combo (on my forms of course)
with a row source to a T_UOM with Ea, LB, OZ, Ft Ect. and store the UOMid in
my part numbers table or just use a value list in my combo and save the
actual UOM abbreviation in my P/N table.

What is a good determining factor for which method to use?
And What to store in my table LB, OZ, EA, ect. or their respective ID's?

I feel linked tables for everything is becoming complicated as i view my
T_Partnumbers all of the data is Greek and meaningless unless i query and
join the appropriate tables, Maybe this is the Database method and i am
afraid to further stray from anything humanly recognizable..

Thank you for your thoughts..
Barry

Barry

It sounds as though you are trying to make sense of the raw tables. Stop
now!

Access tables store data. Access forms (and reports) display data (via
queries).

Don't try to make an Access table work like a spreadsheet -- it isn't one.

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

"Barry A&P" <(E-Mail Removed)> wrote in message
news:CF1E4400-F1E8-4FF1-9DAF-(E-Mail Removed)...
>I am beginning to wonder if i overcomplicate my database. i am going to add
>a
> field to my T_partnumbers for unit of measure (UOM) and can not decide if
> i
> should do it like i have in the past and use a combo (on my forms of
> course)
> with a row source to a T_UOM with Ea, LB, OZ, Ft Ect. and store the UOMid
> in
> my part numbers table or just use a value list in my combo and save the
> actual UOM abbreviation in my P/N table.
>
> What is a good determining factor for which method to use?
> And What to store in my table LB, OZ, EA, ect. or their respective ID's?
>
> I feel linked tables for everything is becoming complicated as i view my
> T_Partnumbers all of the data is Greek and meaningless unless i query and
> join the appropriate tables, Maybe this is the Database method and i am
> afraid to further stray from anything humanly recognizable..
>
> Thank you for your thoughts..
> Barry

A combo can be from a table with only one field and use it bound.

--
Build a little, test a little.


"Barry A&P" wrote:

> I am beginning to wonder if i overcomplicate my database. i am going to add a
> field to my T_partnumbers for unit of measure (UOM) and can not decide if i
> should do it like i have in the past and use a combo (on my forms of course)
> with a row source to a T_UOM with Ea, LB, OZ, Ft Ect. and store the UOMid in
> my part numbers table or just use a value list in my combo and save the
> actual UOM abbreviation in my P/N table.
>
> What is a good determining factor for which method to use?
> And What to store in my table LB, OZ, EA, ect. or their respective ID's?
>
> I feel linked tables for everything is becoming complicated as i view my
> T_Partnumbers all of the data is Greek and meaningless unless i query and
> join the appropriate tables, Maybe this is the Database method and i am
> afraid to further stray from anything humanly recognizable..
>
> Thank you for your thoughts..
> Barry

On Thu, 19 Nov 2009 09:56:05 -0800, Barry A&P
<(E-Mail Removed)> wrote:

>I am beginning to wonder if i overcomplicate my database. i am going to add a
>field to my T_partnumbers for unit of measure (UOM) and can not decide if i
>should do it like i have in the past and use a combo (on my forms of course)
>with a row source to a T_UOM with Ea, LB, OZ, Ft Ect. and store the UOMid in
>my part numbers table or just use a value list in my combo and save the
>actual UOM abbreviation in my P/N table.
>
>What is a good determining factor for which method to use?
>And What to store in my table LB, OZ, EA, ect. or their respective ID's?
>
>I feel linked tables for everything is becoming complicated as i view my
>T_Partnumbers all of the data is Greek and meaningless unless i query and
>join the appropriate tables, Maybe this is the Database method and i am
>afraid to further stray from anything humanly recognizable..

Hi Barry,

I suggest avoiding Values Lists entirely. They must be maintained
separately from the data itself, so you run the risk of them being
redundant or out of sync.

You can use the lookup table as you describe. If you like, you can
use the abbreviation as the primary key and join with that. Then
you'll be able to see the abbreviation without the joining table.

Another example of this is a StateProvince table. If you know the
abbreviations will be unique, you can use them for the primary key
instead of an autonumber.

But I agree with other posters that you shouldn't be looking at your
tables directly to see what's in them. All your related information
should be joined in from other tables using queries, forms or reports.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com

Thank You Armen



"Armen Stein" wrote:

> On Thu, 19 Nov 2009 09:56:05 -0800, Barry A&P
> <(E-Mail Removed)> wrote:
>
> >I am beginning to wonder if i overcomplicate my database. i am going to add a
> >field to my T_partnumbers for unit of measure (UOM) and can not decide if i
> >should do it like i have in the past and use a combo (on my forms of course)
> >with a row source to a T_UOM with Ea, LB, OZ, Ft Ect. and store the UOMid in
> >my part numbers table or just use a value list in my combo and save the
> >actual UOM abbreviation in my P/N table.
> >
> >What is a good determining factor for which method to use?
> >And What to store in my table LB, OZ, EA, ect. or their respective ID's?
> >
> >I feel linked tables for everything is becoming complicated as i view my
> >T_Partnumbers all of the data is Greek and meaningless unless i query and
> >join the appropriate tables, Maybe this is the Database method and i am
> >afraid to further stray from anything humanly recognizable..
>
> Hi Barry,
>
> I suggest avoiding Values Lists entirely. They must be maintained
> separately from the data itself, so you run the risk of them being
> redundant or out of sync.
>
> You can use the lookup table as you describe. If you like, you can
> use the abbreviation as the primary key and join with that. Then
> you'll be able to see the abbreviation without the joining table.
>
> Another example of this is a StateProvince table. If you know the
> abbreviations will be unique, you can use them for the primary key
> instead of an autonumber.
>
> But I agree with other posters that you shouldn't be looking at your
> tables directly to see what's in them. All your related information
> should be joined in from other tables using queries, forms or reports.
>
> Armen Stein
> Microsoft Access MVP
> www.JStreetTech.com
>
> .
>