I've been working on this for some time and have yet to get what I need; I'm
working on a db to keep track of art shows I apply to and attend, there are
three tables:

Art Shows - contains ID(auto number), name, address, Contact , etc.

Application Data - contains ID(auto number), application due date, fees,
year applied, and accepted/declined.

Show Results - contains ID(auto number), gross sales, expenses, net sales

One show may have many application data entries(one for each year applied to
as well as many show results for the same reason. The ID fields are set as
Primary Key in each table, and I've tried various way of linking the tables
with foreign keys set to number. When designing a query I either get an error
message about the link being ambiguous or else it comes back with the fields
I selected from the tables but with no records.

I'm out of ideas...

Rob

I'm wondering if you have a way to connect an Art Show to an Application (or
an Art Show to "Show Results", for that matter).

Although all three have an [ID] field (autonumber), those 3 primary keys are
NOT related to each other, and should NOT be used to try to tie the table
records together.

Which [Art Show] does a particular [Application] belong to?

Which [Art Show] does a particular [ShowResults] belong to?

If you aren't using Foreign Keys, there's no way to trace back to the
"parent" record in the [Art Show] table.

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.

"Rob H" <(E-Mail Removed)> wrote in message
news:2A80045D-0726-4B9D-A081-(E-Mail Removed)...
> I've been working on this for some time and have yet to get what I need;
> I'm
> working on a db to keep track of art shows I apply to and attend, there
> are
> three tables:
>
> Art Shows - contains ID(auto number), name, address, Contact , etc.
>
> Application Data - contains ID(auto number), application due date, fees,
> year applied, and accepted/declined.
>
> Show Results - contains ID(auto number), gross sales, expenses, net sales
>
> One show may have many application data entries(one for each year applied
> to
> as well as many show results for the same reason. The ID fields are set
> as
> Primary Key in each table, and I've tried various way of linking the
> tables
> with foreign keys set to number. When designing a query I either get an
> error
> message about the link being ambiguous or else it comes back with the
> fields
> I selected from the tables but with no records.
>
> I'm out of ideas...
>
>

Jeff,
I left out the foreign keys I was using but yes I have tried relating the
tables this way so for a show I had a foreign key in the application
table(showID/Numer) and then a foreign key also in the application table for
results.

The steps in this would be that in the shows table I would list all shows
that I am looking into, both ones I will apply to and ones I won't. In
either case I would list the application data in the application data table,
this is where I store the importants dates about that show as well as fees ,
and whether or not I applied in a particular year. Then when a show is over
with I would enter the sales details in the results table so that I can then
prepare queries and reports to see which shows I did the best at.

"Jeff Boyce" wrote:

> Rob
>
> I'm wondering if you have a way to connect an Art Show to an Application (or
> an Art Show to "Show Results", for that matter).
>
> Although all three have an [ID] field (autonumber), those 3 primary keys are
> NOT related to each other, and should NOT be used to try to tie the table
> records together.
>
> Which [Art Show] does a particular [Application] belong to?
>
> Which [Art Show] does a particular [ShowResults] belong to?
>
> If you aren't using Foreign Keys, there's no way to trace back to the
> "parent" record in the [Art Show] table.
>
> 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.
>
> "Rob H" <(E-Mail Removed)> wrote in message
> news:2A80045D-0726-4B9D-A081-(E-Mail Removed)...
> > I've been working on this for some time and have yet to get what I need;
> > I'm
> > working on a db to keep track of art shows I apply to and attend, there
> > are
> > three tables:
> >
> > Art Shows - contains ID(auto number), name, address, Contact , etc.
> >
> > Application Data - contains ID(auto number), application due date, fees,
> > year applied, and accepted/declined.
> >
> > Show Results - contains ID(auto number), gross sales, expenses, net sales
> >
> > One show may have many application data entries(one for each year applied
> > to
> > as well as many show results for the same reason. The ID fields are set
> > as
> > Primary Key in each table, and I've tried various way of linking the
> > tables
> > with foreign keys set to number. When designing a query I either get an
> > error
> > message about the link being ambiguous or else it comes back with the
> > fields
> > I selected from the tables but with no records.
> >
> > I'm out of ideas...
> >
> >
>
>
> .
>

Rob

Help me a little bit more here ...

Since you said one Show can have many Applications, and one Show can have
many Results, do you have your tables related this way?

Then, in terms of form design, are you using a main form to display the
[Show] record(s), and a subform for [Applications] and another subform for
[Results]?

(I'm curious though, how a single Show could have more than one Results
record?)

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.

"Rob H" <(E-Mail Removed)> wrote in message
news:A16A6323-45B0-49E5-91F8-(E-Mail Removed)...
> Jeff,
> I left out the foreign keys I was using but yes I have tried relating the
> tables this way so for a show I had a foreign key in the application
> table(showID/Numer) and then a foreign key also in the application table
> for
> results.
>
> The steps in this would be that in the shows table I would list all shows
> that I am looking into, both ones I will apply to and ones I won't. In
> either case I would list the application data in the application data
> table,
> this is where I store the importants dates about that show as well as fees
> ,
> and whether or not I applied in a particular year. Then when a show is
> over
> with I would enter the sales details in the results table so that I can
> then
> prepare queries and reports to see which shows I did the best at.
>
> "Jeff Boyce" wrote:
>
>> Rob
>>
>> I'm wondering if you have a way to connect an Art Show to an Application
>> (or
>> an Art Show to "Show Results", for that matter).
>>
>> Although all three have an [ID] field (autonumber), those 3 primary keys
>> are
>> NOT related to each other, and should NOT be used to try to tie the table
>> records together.
>>
>> Which [Art Show] does a particular [Application] belong to?
>>
>> Which [Art Show] does a particular [ShowResults] belong to?
>>
>> If you aren't using Foreign Keys, there's no way to trace back to the
>> "parent" record in the [Art Show] table.
>>
>> 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.
>>
>> "Rob H" <(E-Mail Removed)> wrote in message
>> news:2A80045D-0726-4B9D-A081-(E-Mail Removed)...
>> > I've been working on this for some time and have yet to get what I
>> > need;
>> > I'm
>> > working on a db to keep track of art shows I apply to and attend, there
>> > are
>> > three tables:
>> >
>> > Art Shows - contains ID(auto number), name, address, Contact , etc.
>> >
>> > Application Data - contains ID(auto number), application due date,
>> > fees,
>> > year applied, and accepted/declined.
>> >
>> > Show Results - contains ID(auto number), gross sales, expenses, net
>> > sales
>> >
>> > One show may have many application data entries(one for each year
>> > applied
>> > to
>> > as well as many show results for the same reason. The ID fields are
>> > set
>> > as
>> > Primary Key in each table, and I've tried various way of linking the
>> > tables
>> > with foreign keys set to number. When designing a query I either get an
>> > error
>> > message about the link being ambiguous or else it comes back with the
>> > fields
>> > I selected from the tables but with no records.
>> >
>> > I'm out of ideas...
>> >
>> >
>>
>>
>> .
>>

On Wed, 31 Mar 2010 11:47:02 -0700, Rob H <(E-Mail Removed)>
wrote:

>The steps in this would be that in the shows table I would list all shows
>that I am looking into, both ones I will apply to and ones I won't.

No. You would NOT list this in the shows *table*.

You would instead use a Form based on Shows, with two Subforms (linked by the
ShowID to the foreign key in the applications and results tables
respectively).

If you're working directly in table datasheets, you're crippling your own
efforts!
--

John W. Vinson [MVP]

I haven't started designing the forms, it's getting the relationships setup
first that has me stumped.
>Since you said one Show can have many Applications, and one Show can have
> many Results, do you have your tables related this way?

This is the answer that I think is key to my issue, would I use the PK(Show
ID, auto number) in the Shows table and then link that to both the
Applications and Results table using a FK(number) in those tables? I've
tried so many different ways I'm not sure if I tried this one or not.

> (I'm curious though, how a single Show could have more than one Results
> record?)
This would be because I could attend the same show year after year and would
want to see the results from each year listed individually.

Hope this helps.

"Jeff Boyce" wrote:

> Rob
>
> Help me a little bit more here ...
>
> Since you said one Show can have many Applications, and one Show can have
> many Results, do you have your tables related this way?
>
> Then, in terms of form design, are you using a main form to display the
> [Show] record(s), and a subform for [Applications] and another subform for
> [Results]?
>
> (I'm curious though, how a single Show could have more than one Results
> record?)
>
> Regards
>
> Jeff Boyce
> Microsoft Access MVP
>

John,
I haven't started on the Forms just yet, I've only added a few rows of
information to the Shows table just to get it started. Once I have the
relationships set then I will create the forms for further data entry.

You and Jeff have both hit on my problem in creating the relationships, if
I understand both of you correctly my PK(auto number) in the Shows table
should be linked to both Application and Results tables via a FK(number) in
each table. It seams I did something similar to this by using the same PK in
the Shows table to multiple other tables and didn't get what I needed.

I will try this again and see if I can get it to work.

"John W. Vinson" wrote:

> On Wed, 31 Mar 2010 11:47:02 -0700, Rob H <(E-Mail Removed)>
> wrote:
>
> >The steps in this would be that in the shows table I would list all shows
> >that I am looking into, both ones I will apply to and ones I won't.
>
> No. You would NOT list this in the shows *table*.
>
> You would instead use a Form based on Shows, with two Subforms (linked by the
> ShowID to the foreign key in the applications and results tables
> respectively).
>
> If you're working directly in table datasheets, you're crippling your own
> efforts!
> --
>
> John W. Vinson [MVP]
> .
>

Rob,

It appears the point that you are missing is that each year an art show is a
different event although it may be the same venue. The year makes it
different. With this in mind, I suggest the following tables .....
TblArtShow
ArtShowID
ArtShowName
ArtShowAddress
ArtShowCity
ArtShowState
ArtShowZipCode
<other fields you may need>

TblArtShowEvent
ArtShowEventID
ArtShowID
ArtShowEventYear
ArtShowEventContact
<contact fields you need>
ApplicationDueDate
ApplicationFee
ApplicationSentDate
Accepted (Yes/No)
GrossSales
Expenses

Note that by recognizing each year an art show is a different event which is
recorded in TblArtShowEvent, application for the event is a one-to-one
relationship with the event so can also be recorded in TblArtShowEvent.
Similiarly, result is also a one-to-one relationship with the event so
result too can be recorded in TblArtShowEvent.

Steve
(E-Mail Removed)



"Rob H" <(E-Mail Removed)> wrote in message
news:2A80045D-0726-4B9D-A081-(E-Mail Removed)...
> I've been working on this for some time and have yet to get what I need;
> I'm
> working on a db to keep track of art shows I apply to and attend, there
> are
> three tables:
>
> Art Shows - contains ID(auto number), name, address, Contact , etc.
>
> Application Data - contains ID(auto number), application due date, fees,
> year applied, and accepted/declined.
>
> Show Results - contains ID(auto number), gross sales, expenses, net sales
>
> One show may have many application data entries(one for each year applied
> to
> as well as many show results for the same reason. The ID fields are set
> as
> Primary Key in each table, and I've tried various way of linking the
> tables
> with foreign keys set to number. When designing a query I either get an
> error
> message about the link being ambiguous or else it comes back with the
> fields
> I selected from the tables but with no records.
>
> I'm out of ideas...
>
>

Oho!

Given the logic you just tried, then why not use the same "application" over
and over ... it's the same "show", right?<g>

I suspect what you're facing is that you have, for example, The Humongous
Bank Commission, which puts on a show each year. However, (and this is a
very big BUT) the show last year IS NOT the same as this year's show. You
have two instances of a show with the same name (and I'm almost willing to
bet that the names are different -- e.g., 2009 HBC and 2010 HBC).

In a way, it might be similar to offering a class on Roman History at the
University. You could have a different venue for each class (i.e.,
classroom), a different sponsor (i.e., instructor), a different ... Some
folks would (legitimately) point out that you most definitely do NOT have
the same show each time, merely shows sponsored by the same organization, or
shows presented in different time frames, venues, etc.

I'm willing to bet that the records for [Applications] and [Results]
pertain, not the the parent, but to the specific child instances.

If this is a fair assessment, then you need a table to keep the parent level
organizations or show-names or ..., then a child table to hold each of the
instances of those. Then it is the primary key of those CHILD instances
that you need to have show up as foreign keys in your [Application] and
[Result] tables.

.... and if you want to know your numbers related to a particular
organization/show-name, use a query and trace your way back through the
CHILD instance to its PARENT.

Good luck!

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.

"Rob H" <(E-Mail Removed)> wrote in message
news:BA05FF8C-7DDF-45DC-A229-(E-Mail Removed)...
>I haven't started designing the forms, it's getting the relationships setup
> first that has me stumped.
>>Since you said one Show can have many Applications, and one Show can have
>> many Results, do you have your tables related this way?
>
> This is the answer that I think is key to my issue, would I use the
> PK(Show
> ID, auto number) in the Shows table and then link that to both the
> Applications and Results table using a FK(number) in those tables? I've
> tried so many different ways I'm not sure if I tried this one or not.
>
>> (I'm curious though, how a single Show could have more than one Results
>> record?)
> This would be because I could attend the same show year after year and
> would
> want to see the results from each year listed individually.
>
> Hope this helps.
>
> "Jeff Boyce" wrote:
>
>> Rob
>>
>> Help me a little bit more here ...
>>
>> Since you said one Show can have many Applications, and one Show can have
>> many Results, do you have your tables related this way?
>>
>> Then, in terms of form design, are you using a main form to display the
>> [Show] record(s), and a subform for [Applications] and another subform
>> for
>> [Results]?
>>
>> (I'm curious though, how a single Show could have more than one Results
>> record?)
>>
>> Regards
>>
>> Jeff Boyce
>> Microsoft Access MVP
>>
>

Jeff,

Thanks for repeating the same thing I said in my response to Rob an hour and
a half ago! Do you have any comments on the tables I suggested to Rob?

Steve





"Jeff Boyce" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Oho!
>
> Given the logic you just tried, then why not use the same "application"
> over and over ... it's the same "show", right?<g>
>
> I suspect what you're facing is that you have, for example, The Humongous
> Bank Commission, which puts on a show each year. However, (and this is a
> very big BUT) the show last year IS NOT the same as this year's show. You
> have two instances of a show with the same name (and I'm almost willing to
> bet that the names are different -- e.g., 2009 HBC and 2010 HBC).
>
> In a way, it might be similar to offering a class on Roman History at the
> University. You could have a different venue for each class (i.e.,
> classroom), a different sponsor (i.e., instructor), a different ... Some
> folks would (legitimately) point out that you most definitely do NOT have
> the same show each time, merely shows sponsored by the same organization,
> or shows presented in different time frames, venues, etc.
>
> I'm willing to bet that the records for [Applications] and [Results]
> pertain, not the the parent, but to the specific child instances.
>
> If this is a fair assessment, then you need a table to keep the parent
> level organizations or show-names or ..., then a child table to hold each
> of the instances of those. Then it is the primary key of those CHILD
> instances that you need to have show up as foreign keys in your
> [Application] and [Result] tables.
>
> ... and if you want to know your numbers related to a particular
> organization/show-name, use a query and trace your way back through the
> CHILD instance to its PARENT.
>
> Good luck!
>
> 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.
>
> "Rob H" <(E-Mail Removed)> wrote in message
> news:BA05FF8C-7DDF-45DC-A229-(E-Mail Removed)...
>>I haven't started designing the forms, it's getting the relationships
>>setup
>> first that has me stumped.
>>>Since you said one Show can have many Applications, and one Show can have
>>> many Results, do you have your tables related this way?
>>
>> This is the answer that I think is key to my issue, would I use the
>> PK(Show
>> ID, auto number) in the Shows table and then link that to both the
>> Applications and Results table using a FK(number) in those tables? I've
>> tried so many different ways I'm not sure if I tried this one or not.
>>
>>> (I'm curious though, how a single Show could have more than one Results
>>> record?)
>> This would be because I could attend the same show year after year and
>> would
>> want to see the results from each year listed individually.
>>
>> Hope this helps.
>>
>> "Jeff Boyce" wrote:
>>
>>> Rob
>>>
>>> Help me a little bit more here ...
>>>
>>> Since you said one Show can have many Applications, and one Show can
>>> have
>>> many Results, do you have your tables related this way?
>>>
>>> Then, in terms of form design, are you using a main form to display the
>>> [Show] record(s), and a subform for [Applications] and another subform
>>> for
>>> [Results]?
>>>
>>> (I'm curious though, how a single Show could have more than one Results
>>> record?)
>>>
>>> Regards
>>>
>>> Jeff Boyce
>>> Microsoft Access MVP
>>>
>>
>
>