The calc below gives the total number of records in the table which is not
what I am after.
Resident Camp Registration has 35 different camp sessions in 1500 records
which when totaled in the report would be the # registered for each camp. I
have tried adding several different criteria to count a total for each of the
different camp sessions without success.

=DCount("[1st Choice Camp Session]","[Resident Camp Registration]")

Does anybody have any ideas?

Thx in advance for the help.

SELECT [1st Choice Camp Session],
Count([1st Choice Camp Session]) as Counts
FROM [Resident Camp Registration]
GROUP BY [1st Choice Camp Session] ;

Now if you have something like 1st Choice Camp Session, 2nd Choice Camp
Session, 3rd Choice Camp Session, etc., across as field headings and that's
what you need to add up, you have a bad design problem.
--
Jerry Whittle, Microsoft Access MVP
Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.

"Steve" wrote:

> The calc below gives the total number of records in the table which is not
> what I am after.
> Resident Camp Registration has 35 different camp sessions in 1500 records
> which when totaled in the report would be the # registered for each camp. I
> have tried adding several different criteria to count a total for each of the
> different camp sessions without success.
>
> =DCount("[1st Choice Camp Session]","[Resident Camp Registration]")
>
> Does anybody have any ideas?
>
> Thx in advance for the help.

A query like:

SELECT CampSession, Count(CampSession) AS NumberRegistered
FROM YourTable
GROUP BY CampSession

will give you what you need, then base a report on the query.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

"Steve" <(E-Mail Removed)> wrote in message
news:390C2E71-0E6B-473B-91DC-(E-Mail Removed)...
> The calc below gives the total number of records in the table which is not
> what I am after.
> Resident Camp Registration has 35 different camp sessions in 1500 records
> which when totaled in the report would be the # registered for each camp.
> I
> have tried adding several different criteria to count a total for each of
> the
> different camp sessions without success.
>
> =DCount("[1st Choice Camp Session]","[Resident Camp Registration]")
>
> Does anybody have any ideas?
>
> Thx in advance for the help.

This looks as if it is part of a query. I was trying to do it in the report.
Is the query a better approach?

"Jerry Whittle" wrote:

> SELECT [1st Choice Camp Session],
> Count([1st Choice Camp Session]) as Counts
> FROM [Resident Camp Registration]
> GROUP BY [1st Choice Camp Session] ;
>
> Now if you have something like 1st Choice Camp Session, 2nd Choice Camp
> Session, 3rd Choice Camp Session, etc., across as field headings and that's
> what you need to add up, you have a bad design problem.
> --
> Jerry Whittle, Microsoft Access MVP
> Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.
>
> "Steve" wrote:
>
> > The calc below gives the total number of records in the table which is not
> > what I am after.
> > Resident Camp Registration has 35 different camp sessions in 1500 records
> > which when totaled in the report would be the # registered for each camp. I
> > have tried adding several different criteria to count a total for each of the
> > different camp sessions without success.
> >
> > =DCount("[1st Choice Camp Session]","[Resident Camp Registration]")
> >
> > Does anybody have any ideas?
> >
> > Thx in advance for the help.

"Steve" <(E-Mail Removed)> wrote in message
news:3FEBD6B6-6765-4E50-973E-(E-Mail Removed)...
> This looks as if it is part of a query. I was trying to do it in the
> report.
> Is the query a better approach?

A query is much faster than calculating in a report, and there are no timing
issues if you are also running code.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

I did as you suggested. the query returns 32 lines. How do I all 32 items to
appear on the report? The rest of the report is looking at a table. I'm
thinking a dlookup but I'm not of the syntax.

"Arvin Meyer [MVP]" wrote:

> "Steve" <(E-Mail Removed)> wrote in message
> news:3FEBD6B6-6765-4E50-973E-(E-Mail Removed)...
> > This looks as if it is part of a query. I was trying to do it in the
> > report.
> > Is the query a better approach?
>
> A query is much faster than calculating in a report, and there are no timing
> issues if you are also running code.
> --
> Arvin Meyer, MCP, MVP
> http://www.datastrat.com
> http://www.mvps.org/access
> http://www.accessmvp.com
>
>
>

I did as you suggested. The query returns 32 lines. How do I get all 32 items
to
appear on the report? The rest of the report is looking at a table. I'm
thinking a dlookup but I'm not sure of the syntax.


"Arvin Meyer [MVP]" wrote:

> "Steve" <(E-Mail Removed)> wrote in message
> news:3FEBD6B6-6765-4E50-973E-(E-Mail Removed)...
> > This looks as if it is part of a query. I was trying to do it in the
> > report.
> > Is the query a better approach?
>
> A query is much faster than calculating in a report, and there are no timing
> issues if you are also running code.
> --
> Arvin Meyer, MCP, MVP
> http://www.datastrat.com
> http://www.mvps.org/access
> http://www.accessmvp.com
>
>
>

Assuming you have a matching key, use a subreport. Running DLookup will be
even slower than a report calculation because it has to go back to the
source 32 times.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

"Steve" <(E-Mail Removed)> wrote in message
news:307E5635-BE3A-4A66-A512-(E-Mail Removed)...
>I did as you suggested. The query returns 32 lines. How do I get all 32
>items
> to
> appear on the report? The rest of the report is looking at a table. I'm
> thinking a dlookup but I'm not sure of the syntax.
>
>
> "Arvin Meyer [MVP]" wrote:
>
>> "Steve" <(E-Mail Removed)> wrote in message
>> news:3FEBD6B6-6765-4E50-973E-(E-Mail Removed)...
>> > This looks as if it is part of a query. I was trying to do it in the
>> > report.
>> > Is the query a better approach?
>>
>> A query is much faster than calculating in a report, and there are no
>> timing
>> issues if you are also running code.
>> --
>> Arvin Meyer, MCP, MVP
>> http://www.datastrat.com
>> http://www.mvps.org/access
>> http://www.accessmvp.com
>>
>>
>>

Sorry for the late response. I was on vacation.

I am familiar will the Dlookup but not the subreport or the matching key.
Could you please provide more information?

"Arvin Meyer [MVP]" wrote:

> Assuming you have a matching key, use a subreport. Running DLookup will be
> even slower than a report calculation because it has to go back to the
> source 32 times.
> --
> Arvin Meyer, MCP, MVP
> http://www.datastrat.com
> http://www.mvps.org/access
> http://www.accessmvp.com
>
> "Steve" <(E-Mail Removed)> wrote in message
> news:307E5635-BE3A-4A66-A512-(E-Mail Removed)...
> >I did as you suggested. The query returns 32 lines. How do I get all 32
> >items
> > to
> > appear on the report? The rest of the report is looking at a table. I'm
> > thinking a dlookup but I'm not sure of the syntax.
> >
> >
> > "Arvin Meyer [MVP]" wrote:
> >
> >> "Steve" <(E-Mail Removed)> wrote in message
> >> news:3FEBD6B6-6765-4E50-973E-(E-Mail Removed)...
> >> > This looks as if it is part of a query. I was trying to do it in the
> >> > report.
> >> > Is the query a better approach?
> >>
> >> A query is much faster than calculating in a report, and there are no
> >> timing
> >> issues if you are also running code.
> >> --
> >> Arvin Meyer, MCP, MVP
> >> http://www.datastrat.com
> >> http://www.mvps.org/access
> >> http://www.accessmvp.com
> >>
> >>
> >>
>
>
>