Jorge said:
OK I'll try..
DOG.db, CAT.db, RECV.db
DOG has Food$, Carrier$, Shots$ Primary key = A
CAT has Food$, Carrier$, Shots$ Primary key = B
These 2 db's can only have one entry pertaining to food etc
So would you call these a table? I suppose.
I have the record set to 1.
RECV has Name, Address etc.. and type of transaction (DOG or CAT)
Based on a check mark (on/off) in DOG or CAT it will display the
current fields within either Dog or Cat for Food$, Carrier$, Shots$
Does this sound okay?
DOG CAT | Dog Food $5 |
| Dog Carrier $5 |
| Dog Shots $5 |
|
| --------------------------
The dog & cat & Recv databases have quite a few more entries but I am
just trying to keep it simple.
Thank -u
Jorge
I have a technical question and a design comment. The technical
question is, are you in fact working with Microsoft Access? Where do
these ".db" file types (?) come from? Are you using Access, but linking
to tables/files from another database system, possibly xBase? Or are
you working within another database system entirely? If the latter, my
design comment would still apply, I think, but I can't offer much in the
way of technical advice.
Now for the design comment. I'll assume that your DOG.db, CAT.db, and
RECV.db represent what are either in fact or in practice, three logical
tables. I understand that what you've posted is a simplification of the
actual design. For the purposes of this discussion, I'll consider that
"DOG" is a table, "CAT" is a table, and "RECV" is a table of
transactions involving the first two tables. But this design is flawed,
because you are storing essential information in the table name (DOG vs.
CAT) itself.
If DOG and CAT contain a set of fields that they hold in common, and
which you need to work with (as far as RECV is concerned) as though
there were no difference between the two tables except for the fact that
a particular record happens to represent a dog or a cat, then those
fields should really be stored in a single table. That table would
abstract this essential quality of dogs and cats. For example, you
would do better to have a table called (maybe) ANIMAL which would
contain these fields:
Table: ANIMAL
Field: AnimalID (primary key)
Field: AnimalType (dog, cat, goldfish, whatever)
Field: Food
Field: Carrier
Field: Shots
This ANIMAL table and its key AnimalID would then be referred to by your
RECV transaction table, rather than any individual table for each animal
type.
You may or may not need additional, special fields that are specific to
each type of animal. This is a sub-typing arrangement -- CAT is a
subtype of ANIMAL. In such a case, you could either include the special
fields for each animal in the ANIMAL table and show them as needed, or
you could have a set of separate tables, one for each type of animal,
with each of these tables in a one-to-one relationship with the ANIMAL
table (ANIMAL being primary, however). That way, you could have
separate forms for each type of animal if you want, basing each on a
query that joins the ANIMAL table with the appropriate subtype table,
and you could also have a form based on ANIMAL alone, but show an
appropriate subform based on the AnimalType of the current record
(swapping or showing and hiding subforms as needed).
