Multiple tabs and relationships

[Kelly]

I have created a form that has multiple tabs. Does
anyone know how to create the relationships between the
tables so Access recognizes that all the tabs are for one
record?

 

[Rebecca Riordan]

The records are bound at the form level, not the tab level, so unless you've
used sub-forms, all of the bound controls, including those on the tabs, will
display information from the same record.

--
Rebecca Riordan, MVP

Designing Relational Database Systems
Microsoft SQL Server 2000 Programming Step by Step
Microsoft ADO.NET Step by Step

http://www.microsoft.com/mspress

Blessed are they who can laugh at themselves,
for they shall never cease to be amused...

 

[John Vinson]

I have created a form that has multiple tabs. Does
anyone know how to create the relationships between the
tables so Access recognizes that all the tabs are for one
record?

This has ABSOLUTELY nothing to do with relationships.

Tabs on a Form are simply a way of arranging screen real estate. The
controls on those Tabs all will be bound to the Recordsource of the
form; moving from one tab to another will (unless you do something to
prevent it) stay on the same record.

If you're designing your form first and then creating the table to fit
it, *and* if you have so many fields in your table that you need
multiple tabs, you very likely have a imperfectly normalized table
structure! How is your table structured? What's the Recordsource for
this form?

 

[Guest]

Thanks so much for replying to my question, John. Maybe
I approached the whole thing wrong. ?. I created a
different table and form for each tab...then inserted
each in the "main" form as subforms. Should I just be
using one table?

 

[John Vinson]

Thanks so much for replying to my question, John. Maybe
I approached the whole thing wrong. ?. I created a
different table and form for each tab...then inserted
each in the "main" form as subforms. Should I just be
using one table?

Given that I have NO trace of a clue about what data you are modeling,
or how it is logically related, I have no idea.

You may want to read up a bit on "Normalization". If you have no idea
whether your data represents one Entity or many, or (equivalently)
whether it should be in one Table or several, you're at risk of coming
up with a non-normalized design; and that will be much harder to work
with than if your design were better.

 

[Kelly]

Hi again-
This will be the last time I bug you. I just really need
to figure this out. I'm building something similar to
Raiser's Edge (a database used by non-profits) where one
record equals one contact. Each tab contains info on
that contact, e.g.: one tab is personal info, another is
a gift giving history, another is a list of events that
contact attended, etc.
Many thanks for your time and patience. I think I'm
simply in over my head here.

 

[John Vinson]

Hi again-
This will be the last time I bug you. I just really need
to figure this out. I'm building something similar to
Raiser's Edge (a database used by non-profits) where one
record equals one contact. Each tab contains info on
that contact, e.g.: one tab is personal info, another is
a gift giving history, another is a list of events that
contact attended, etc.
Many thanks for your time and patience. I think I'm
simply in over my head here.

Identify your Entities: real-life persons, things, or events. There
are three entities: Donors; Gifts; Events. I'm sure there are more -
they may indeed be the tables on your tab pages.

Now identify how these entities *are related*. A Gift is of no use to
you as the database user unless you know who gave it; you have
(probably) a one (donor) to many (gifts) relationship. Similarly, each
donor will probably attend multiple Events, and each Event will be
attended by many donors - a many to many relationship, which requires
a third table (EventsAttended, with links to the Events table and to
the Donors table). Therefore you don't really want to have a table of
all the Donors (with no gift information) on one tab, and a table of
Gifts (with no information about who gave them) on another tab, and a
table of Events (not related to either of the above) on a third!

You should consider having a "nested" structure: a Mainform for Donor;
a Subform for that donor's Gifts; another Subform (of the main form)
for events attended; and so on.

The relational way of thinking takes some getting used to, but once
you get the hang of it you'll find that it's extremely powerful at
economically modeling information.