Hal

see comment in-line below...

"Hal" wrote in message
...
Jeff, again thanks. Here's what I have:
Building table= BuildingNumber (alphanum) key, address, property manager,
accountNumber (alphanum), supplierID. (one-to-many relationship to
"BuildingNumber).

I don't understand. How can this table have a one-to-many relationship to
BuildingNumber? Tables have relationships to other tables. I also don't
understand how a "building" can have a "supplier" (supplierID). And I don't
understand your situation well enough to know how [accountNumber] relates
.... is it an attribute of the building itself, the [property manager], or
????

Utility Accounts Table= SupplierID, (number), BuildingID, SupplierID,
AccountNumber, meterNumber, +accounting fields.

How come [AccountNumber] and [SupplierID] (twice?) show up in this table,
too? A well-normalized relational database doesn't need duplicated data
(same data in multiple tables).

Utiltiy Supplier Table= related to Utility Account Table (one-to-Many
through "supplierID).

What does this table hold? ?Attributes of Utility Suppliers?

Utility Category Table= related to Utility Supplier Table (one-to-many
throught "utilityID")

If this really contains "utility categories", then it wouldn't be related
via [UtilityID], it would be related via a [UtilityCategoryID] field.

I'm trying to capture all of the utiltiy transactions; monthly consumption
(in kwh, gallons, therms, btu, etc for each type of utility) and cost, and
be
able to show those transaction by building or account using the
"AccountNumber"
Based upon what you've said so far, I may not be thinking about these
relationships in a proper context. I'm learning the program and have a
need
to manipulate all of these data elements.
Thanks for your thinking and time. Any insight to get me on track will be
helpful.
--
Thanks, Hal

I get the impression that the table structure you're using is meaningful,
but I don't get the meaning!g

To get the best use of Access' relationally-oriented features/functions, you
have to 'feed' it well-normalized data. If you don't, you'll pay later. So
it's a "pay now (learn normalization) or pay later (come up with kludges and
workarounds)" situation.

If this were mine, I'd turn off the PC, grab paper and pencil, and write
down what I believe the entities to be. Clearly, you have buildings ... so
that's probably one of the entities. And you have utilities (do you mean
water, sewer, electrical, etc., or Power Company A, Power Company B, ...?).
So jot down just the names of the entities.

Then draw lines between them and jot down statements like:

One building can have multiple utilities.

One utility can serve multiple buildings.

One building can have monthly transactions for each (of its multiple)
utility(ies).

NOTE -- I don't know if any of these statements are true -- only you do!
Write down what you know.

Then use those statements to fill in the relationships (along the lines)
between/among your entities.

Now add attributes to each entity. I'd be willing to bet that Buildings do
not have an attribute of "supplier" (but hey, I don't know your situation!).

Try the above and post back with what you come up with. There's a fairly
steep learning curve for relational and normalization, so again, it's "pay
now or ....!

Regards

Jeff Boyce
Microsoft Office/Access MVP