saved queries based on other saved queries vs. one big query in a form's module using DAO

[Richard Hollenbeck]

I have a big mess on my hands. I've been making many work-around to a
flawed set of queries I made and now it's finally back to the drawing board.
I made a few changes and now I can't figure out why it quit working. The
problem is that my mess is now so big that I don't know where to start over.
I don't want to go back to a saved backup. I have several saved queries,
each built on each other, that a report is based on. Each saved query is in
excess of ten lines of code. It's way too complicated to troubleshoot and
I'd like to start over. I'd like to avoid saved queries altogether and
create a DAO.database and DAO.recordset based on one big StrSQL statement
inside the report's module. then assign some of the values to textboxes
and/or labels within the report.

The report displays any and/or all students' grades in a course for each
activity in that course (one page per student). The activities are grouped
by "groups." The activities each have a weight within that group and the
groups have a weight within each course. For example, the final exam may be
worth 45% of the group "exams." and the "exams" group may be worth 20% of
the total grade in that course. The 45%, in this example, would be the
[activities].[activityWeight] and the 20% in the same example would be the
[groups].[groupWeight]. The activity percentage weight would be the current
activity's weight divided by the sum of all activityWeights within that
group times that group's groupWeight. Brrrr! I get confused just
describing my situation.

So I need to show [courses].[courseCode], [courses].[courseDescription],
[groups.groupID], [groups].[groupDescription], [groups].[groupWeight],
[activities].[activityID], [activities].[activityDescription],
[activities].[activityWeight], [students].[studentName],
[students].[StudentID], and [studentScores].[score]. So far, that's pretty
easy. I can do that easily either by writing the SQL code directly or by
using the QBE tool.

***** But ***** within each group, I also need to calculate the group's
weight against its percentage of the entire course's group weights and the
same with the activity weight as a percentage of the sum of activity
weights within each group. Once I get these summary figures I can plug the
results into text boxes or labels in the report, grouped by each student
within each course.

The first time I tried this I made a query that got the summary infomation
and saved it as a query. Then I made another query to gather the other
information I needed and also referenced the first query to get the
summaries. I also did this second query in the QBE.

There has GOT to be a better way. Upon request I will cheerfully post all
the queries involved in the original report. I'm thinking about starting
from scratch.

Should I make subqueries in the main query to get the summary data instead
of referencing an existing query in the QBE? Can I do all this inside the
report's module? Do I need saved queries at all? If I had it in the module
would I use DAO (I think I prefer it over ADO)?
I know this sounds confusing. It's even more confusing when you see how I
made it work before. I had to divide some numbers by 100 and 1000 and other
numbers I had to multiply by ten or 100, etc., just to make the numbers
calculate correctly. It got really crazy. I was never sure which query I
needed to modify. I'm looking forward to a simpler approach.

Many thanks for any suggestions. . .

Rich Hollenbeck

 

[Ted Allen]

Hi Richard,

It sounds like you could probably use subqueries or
domain aggregate functions to do what you want to do,
rather than having nested queries. Sometimes I find this
easier to deal with because I can see everything at once.

I'm not sure, but from reading your example it sounds
like you would also have the option of using domain
aggregate functions inside your report directly if you
want to keep the query simple.

Domain aggregate functions can be very useful when
combined with your field values. For example, you could
use DSum() to return the sum of all activity weights with
a GroupID matching the current activity. The key of
course is to be able to properly concatenate the criteria
condition which limits the domain.

Calculating the summary values in the query has some
advantages. One big advantage is that the query can
easily be used for other forms or reports in the future.
On the other hand, calculating the values in the report
makes it a little easier to see how each particular value
is being calculated (and it is easy to copy the formulas
to fields in other forms and/or reports if needed).

Personally I try to avoid doing things like this in VBA,
because in my working environment if I ever leave it is
very unlikely that my replacement will be able to figure
out what I was doing.

This is all general info. Hopefully it will help give
you some insight. If you have any specific questions on
how to use domain aggregate functions or subqueries for
your situation, it would probably be a good idea to post
back with a specific example of a single calculation
formula, and the field values involved (as well as their
table relationships if they come from multiple tables).

HTH, Ted Allen

-----Original Message-----
I have a big mess on my hands. I've been making many work-around to a
flawed set of queries I made and now it's finally back to the drawing board.
I made a few changes and now I can't figure out why it quit working. The
problem is that my mess is now so big that I don't know where to start over.
I don't want to go back to a saved backup. I have several saved queries,
each built on each other, that a report is based on. Each saved query is in
excess of ten lines of code. It's way too complicated to troubleshoot and
I'd like to start over. I'd like to avoid saved queries altogether and
create a DAO.database and DAO.recordset based on one big StrSQL statement
inside the report's module. then assign some of the values to textboxes
and/or labels within the report.

The report displays any and/or all students' grades in a course for each
activity in that course (one page per student). The activities are grouped
by "groups." The activities each have a weight within that group and the
groups have a weight within each course. For example, the final exam may be
worth 45% of the group "exams." and the "exams" group may be worth 20% of
the total grade in that course. The 45%, in this example, would be the
[activities].[activityWeight] and the 20% in the same example would be the
[groups].[groupWeight]. The activity percentage weight would be the current
activity's weight divided by the sum of all activityWeights within that
group times that group's groupWeight. Brrrr! I get confused just
describing my situation.

So I need to show [courses].[courseCode], [courses]. [courseDescription],
[groups.groupID], [groups].[groupDescription], [groups]. [groupWeight],
[activities].[activityID], [activities]. [activityDescription],
[activities].[activityWeight], [students].[studentName],
[students].[StudentID], and [studentScores].[score]. So far, that's pretty
easy. I can do that easily either by writing the SQL code directly or by
using the QBE tool.

***** But ***** within each group, I also need to calculate the group's
weight against its percentage of the entire course's group weights and the
same with the activity weight as a percentage of the sum of activity
weights within each group. Once I get these summary figures I can plug the
results into text boxes or labels in the report, grouped by each student
within each course.

The first time I tried this I made a query that got the summary infomation
and saved it as a query. Then I made another query to gather the other
information I needed and also referenced the first query to get the
summaries. I also did this second query in the QBE.

There has GOT to be a better way. Upon request I will cheerfully post all
the queries involved in the original report. I'm thinking about starting
from scratch.

Should I make subqueries in the main query to get the summary data instead
of referencing an existing query in the QBE? Can I do all this inside the
report's module? Do I need saved queries at all? If I had it in the module
would I use DAO (I think I prefer it over ADO)?
I know this sounds confusing. It's even more confusing when you see how I
made it work before. I had to divide some numbers by 100 and 1000 and other
numbers I had to multiply by ten or 100, etc., just to make the numbers
calculate correctly. It got really crazy. I was never sure which query I
needed to modify. I'm looking forward to a simpler approach.

Many thanks for any suggestions. . .

Rich Hollenbeck


.

 

[Richard Hollenbeck]

Thank you very much. You gave me a lot of new stuff to chew on so my "real"
reply won't arrive until I have a chance to digest all you have taught me.
I have a book, but it is so thick it would take me years to read it all.
I'll concentrate on learning about "domain aggregate functions" and "DSum()"
before I reply. That way your help will be most useful. When I do reply
I'll also post whatever I learned so that anybody else following this post,
perhaps another newbie like me, may also benefit.

Thanks again, Ted.

Rich Hollenbeck

Hi Richard,

It sounds like you could probably use subqueries or
domain aggregate functions to do what you want to do,
rather than having nested queries. Sometimes I find this
easier to deal with because I can see everything at once.

I'm not sure, but from reading your example it sounds
like you would also have the option of using domain
aggregate functions inside your report directly if you
want to keep the query simple.

Domain aggregate functions can be very useful when
combined with your field values. For example, you could
use DSum() to return the sum of all activity weights with
a GroupID matching the current activity. The key of
course is to be able to properly concatenate the criteria
condition which limits the domain.

Calculating the summary values in the query has some
advantages. One big advantage is that the query can
easily be used for other forms or reports in the future.
On the other hand, calculating the values in the report
makes it a little easier to see how each particular value
is being calculated (and it is easy to copy the formulas
to fields in other forms and/or reports if needed).

Personally I try to avoid doing things like this in VBA,
because in my working environment if I ever leave it is
very unlikely that my replacement will be able to figure
out what I was doing.

This is all general info. Hopefully it will help give
you some insight. If you have any specific questions on
how to use domain aggregate functions or subqueries for
your situation, it would probably be a good idea to post
back with a specific example of a single calculation
formula, and the field values involved (as well as their
table relationships if they come from multiple tables).

HTH, Ted Allen

-----Original Message-----
I have a big mess on my hands. I've been making many work-around to a
flawed set of queries I made and now it's finally back to the drawing board.
I made a few changes and now I can't figure out why it quit working. The
problem is that my mess is now so big that I don't know where to start over.
I don't want to go back to a saved backup. I have several saved queries,
each built on each other, that a report is based on. Each saved query is in
excess of ten lines of code. It's way too complicated to troubleshoot and
I'd like to start over. I'd like to avoid saved queries altogether and
create a DAO.database and DAO.recordset based on one big StrSQL statement
inside the report's module. then assign some of the values to textboxes
and/or labels within the report.

The report displays any and/or all students' grades in a course for each
activity in that course (one page per student). The activities are grouped
by "groups." The activities each have a weight within that group and the
groups have a weight within each course. For example, the final exam may be
worth 45% of the group "exams." and the "exams" group may be worth 20% of
the total grade in that course. The 45%, in this example, would be the
[activities].[activityWeight] and the 20% in the same example would be the
[groups].[groupWeight]. The activity percentage weight would be the current
activity's weight divided by the sum of all activityWeights within that
group times that group's groupWeight. Brrrr! I get confused just
describing my situation.

So I need to show [courses].[courseCode], [courses]. [courseDescription],
[groups.groupID], [groups].[groupDescription], [groups]. [groupWeight],
[activities].[activityID], [activities]. [activityDescription],
[activities].[activityWeight], [students].[studentName],
[students].[StudentID], and [studentScores].[score]. So far, that's pretty
easy. I can do that easily either by writing the SQL code directly or by
using the QBE tool.

***** But ***** within each group, I also need to calculate the group's
weight against its percentage of the entire course's group weights and the
same with the activity weight as a percentage of the sum of activity
weights within each group. Once I get these summary figures I can plug the
results into text boxes or labels in the report, grouped by each student
within each course.

The first time I tried this I made a query that got the summary infomation
and saved it as a query. Then I made another query to gather the other
information I needed and also referenced the first query to get the
summaries. I also did this second query in the QBE.

There has GOT to be a better way. Upon request I will cheerfully post all
the queries involved in the original report. I'm thinking about starting
from scratch.

Should I make subqueries in the main query to get the summary data instead
of referencing an existing query in the QBE? Can I do all this inside the
report's module? Do I need saved queries at all? If I had it in the module
would I use DAO (I think I prefer it over ADO)?
I know this sounds confusing. It's even more confusing when you see how I
made it work before. I had to divide some numbers by 100 and 1000 and other
numbers I had to multiply by ten or 100, etc., just to make the numbers
calculate correctly. It got really crazy. I was never sure which query I
needed to modify. I'm looking forward to a simpler approach.

Many thanks for any suggestions. . .

Rich Hollenbeck


.

 

[Ted Allen]

Sounds like a good plan. I'll keep an eye out for future
posts.

-Ted

-----Original Message-----
Thank you very much. You gave me a lot of new stuff to chew on so my "real"
reply won't arrive until I have a chance to digest all you have taught me.
I have a book, but it is so thick it would take me years to read it all.
I'll concentrate on learning about "domain aggregate functions" and "DSum()"
before I reply. That way your help will be most useful. When I do reply
I'll also post whatever I learned so that anybody else following this post,
perhaps another newbie like me, may also benefit.

Thanks again, Ted.

Rich Hollenbeck

Hi Richard,

It sounds like you could probably use subqueries or
domain aggregate functions to do what you want to do,
rather than having nested queries. Sometimes I find this
easier to deal with because I can see everything at once.

I'm not sure, but from reading your example it sounds
like you would also have the option of using domain
aggregate functions inside your report directly if you
want to keep the query simple.

Domain aggregate functions can be very useful when
combined with your field values. For example, you could
use DSum() to return the sum of all activity weights with
a GroupID matching the current activity. The key of
course is to be able to properly concatenate the criteria
condition which limits the domain.

Calculating the summary values in the query has some
advantages. One big advantage is that the query can
easily be used for other forms or reports in the future.
On the other hand, calculating the values in the report
makes it a little easier to see how each particular value
is being calculated (and it is easy to copy the formulas
to fields in other forms and/or reports if needed).

Personally I try to avoid doing things like this in VBA,
because in my working environment if I ever leave it is
very unlikely that my replacement will be able to figure
out what I was doing.

This is all general info. Hopefully it will help give
you some insight. If you have any specific questions on
how to use domain aggregate functions or subqueries for
your situation, it would probably be a good idea to post
back with a specific example of a single calculation
formula, and the field values involved (as well as their
table relationships if they come from multiple tables).

HTH, Ted Allen

-----Original Message-----
I have a big mess on my hands. I've been making many work-around to a
flawed set of queries I made and now it's finally back to the drawing board.
I made a few changes and now I can't figure out why it quit working. The
problem is that my mess is now so big that I don't

know
where to start over.

I don't want to go back to a saved backup. I have several saved queries,
each built on each other, that a report is based on. Each saved query is in
excess of ten lines of code. It's way too complicated to troubleshoot and
I'd like to start over. I'd like to avoid saved

queries
altogether and

create a DAO.database and DAO.recordset based on one

big
StrSQL statement

inside the report's module. then assign some of the values to textboxes
and/or labels within the report.

The report displays any and/or all students' grades

in a
course for each

activity in that course (one page per student). The activities are grouped
by "groups." The activities each have a weight within that group and the
groups have a weight within each course. For example, the final exam may be
worth 45% of the group "exams." and the "exams" group may be worth 20% of
the total grade in that course. The 45%, in this example, would be the
[activities].[activityWeight] and the 20% in the same example would be the
[groups].[groupWeight]. The activity percentage

weight
would be the current

activity's weight divided by the sum of all activityWeights within that
group times that group's groupWeight. Brrrr! I get confused just
describing my situation.

So I need to show [courses].[courseCode], [courses]. [courseDescription],
[groups.groupID], [groups].[groupDescription],

[groups].
[groupWeight],

[activities].[activityID], [activities]. [activityDescription],
[activities].[activityWeight], [students]. [studentName],
[students].[StudentID], and [studentScores].[score].

So
far, that's pretty

easy. I can do that easily either by writing the SQL code directly or by
using the QBE tool.

***** But ***** within each group, I also need to calculate the group's
weight against its percentage of the entire course's group weights and the
same with the activity weight as a percentage of the

sum
of activity

weights within each group. Once I get these summary figures I can plug the
results into text boxes or labels in the report,

grouped
by each student

within each course.

The first time I tried this I made a query that got

the
summary infomation

and saved it as a query. Then I made another query to gather the other
information I needed and also referenced the first

query
to get the

summaries. I also did this second query in the QBE.

There has GOT to be a better way. Upon request I will cheerfully post all
the queries involved in the original report. I'm thinking about starting
from scratch.

Should I make subqueries in the main query to get the summary data instead
of referencing an existing query in the QBE? Can I do all this inside the
report's module? Do I need saved queries at all? If

I
had it in the module

would I use DAO (I think I prefer it over ADO)?
I know this sounds confusing. It's even more

confusing
when you see how I

made it work before. I had to divide some numbers by 100 and 1000 and other
numbers I had to multiply by ten or 100, etc., just to make the numbers
calculate correctly. It got really crazy. I was

never
sure which query I

needed to modify. I'm looking forward to a simpler approach.

Many thanks for any suggestions. . .

Rich Hollenbeck


.

.

 

[Richard Hollenbeck]

Yes, DSum() is working very well. Thank you for pointing me in the right
direction. Also, my query can now be much simpler by removing unessential
fields from it and using Nz(DLookup()) in the report instead. Very cool.

Sounds like a good plan. I'll keep an eye out for future
posts.

-Ted

-----Original Message-----
Thank you very much. You gave me a lot of new stuff to chew on so my "real"
reply won't arrive until I have a chance to digest all you have taught me.
I have a book, but it is so thick it would take me years to read it all.
I'll concentrate on learning about "domain aggregate functions" and "DSum()"
before I reply. That way your help will be most useful. When I do reply
I'll also post whatever I learned so that anybody else following this post,
perhaps another newbie like me, may also benefit.

Thanks again, Ted.

Rich Hollenbeck

Hi Richard,

It sounds like you could probably use subqueries or
domain aggregate functions to do what you want to do,
rather than having nested queries. Sometimes I find this
easier to deal with because I can see everything at once.

I'm not sure, but from reading your example it sounds
like you would also have the option of using domain
aggregate functions inside your report directly if you
want to keep the query simple.

Domain aggregate functions can be very useful when
combined with your field values. For example, you could
use DSum() to return the sum of all activity weights with
a GroupID matching the current activity. The key of
course is to be able to properly concatenate the criteria
condition which limits the domain.

Calculating the summary values in the query has some
advantages. One big advantage is that the query can
easily be used for other forms or reports in the future.
On the other hand, calculating the values in the report
makes it a little easier to see how each particular value
is being calculated (and it is easy to copy the formulas
to fields in other forms and/or reports if needed).

Personally I try to avoid doing things like this in VBA,
because in my working environment if I ever leave it is
very unlikely that my replacement will be able to figure
out what I was doing.

This is all general info. Hopefully it will help give
you some insight. If you have any specific questions on
how to use domain aggregate functions or subqueries for
your situation, it would probably be a good idea to post
back with a specific example of a single calculation
formula, and the field values involved (as well as their
table relationships if they come from multiple tables).

HTH, Ted Allen
-----Original Message-----
I have a big mess on my hands. I've been making many
work-around to a
flawed set of queries I made and now it's finally back
to the drawing board.
I made a few changes and now I can't figure out why it
quit working. The
problem is that my mess is now so big that I don't know
where to start over.
I don't want to go back to a saved backup. I have
several saved queries,
each built on each other, that a report is based on.
Each saved query is in
excess of ten lines of code. It's way too complicated
to troubleshoot and
I'd like to start over. I'd like to avoid saved queries
altogether and
create a DAO.database and DAO.recordset based on one big
StrSQL statement
inside the report's module. then assign some of the
values to textboxes
and/or labels within the report.

The report displays any and/or all students' grades in a
course for each
activity in that course (one page per student). The
activities are grouped
by "groups." The activities each have a weight within
that group and the
groups have a weight within each course. For example,
the final exam may be
worth 45% of the group "exams." and the "exams" group
may be worth 20% of
the total grade in that course. The 45%, in this
example, would be the
[activities].[activityWeight] and the 20% in the same
example would be the
[groups].[groupWeight]. The activity percentage weight
would be the current
activity's weight divided by the sum of all
activityWeights within that
group times that group's groupWeight. Brrrr! I get
confused just
describing my situation.

So I need to show [courses].[courseCode], [courses].
[courseDescription],
[groups.groupID], [groups].[groupDescription], [groups].
[groupWeight],
[activities].[activityID], [activities].
[activityDescription],
[activities].[activityWeight], [students]. [studentName],
[students].[StudentID], and [studentScores].[score]. So
far, that's pretty
easy. I can do that easily either by writing the SQL
code directly or by
using the QBE tool.

***** But ***** within each group, I also need to
calculate the group's
weight against its percentage of the entire course's
group weights and the
same with the activity weight as a percentage of the sum
of activity
weights within each group. Once I get these summary
figures I can plug the
results into text boxes or labels in the report, grouped
by each student
within each course.

The first time I tried this I made a query that got the
summary infomation
and saved it as a query. Then I made another query to
gather the other
information I needed and also referenced the first query
to get the
summaries. I also did this second query in the QBE.

There has GOT to be a better way. Upon request I will
cheerfully post all
the queries involved in the original report. I'm
thinking about starting
from scratch.

Should I make subqueries in the main query to get the
summary data instead
of referencing an existing query in the QBE? Can I do
all this inside the
report's module? Do I need saved queries at all? If I
had it in the module
would I use DAO (I think I prefer it over ADO)?
I know this sounds confusing. It's even more confusing
when you see how I
made it work before. I had to divide some numbers by
100 and 1000 and other
numbers I had to multiply by ten or 100, etc., just to
make the numbers
calculate correctly. It got really crazy. I was never
sure which query I
needed to modify. I'm looking forward to a simpler
approach.

Many thanks for any suggestions. . .

Rich Hollenbeck


.

.

 

[Ted Allen]

My pleasure, glad it helped.

-----Original Message-----
Yes, DSum() is working very well. Thank you for pointing me in the right
direction. Also, my query can now be much simpler by removing unessential
fields from it and using Nz(DLookup()) in the report instead. Very cool.

Sounds like a good plan. I'll keep an eye out for future
posts.

-Ted

-----Original Message-----
Thank you very much. You gave me a lot of new stuff

to
chew on so my "real"

reply won't arrive until I have a chance to digest all you have taught me.
I have a book, but it is so thick it would take me

years
to read it all.

I'll concentrate on learning about "domain aggregate functions" and "DSum()"
before I reply. That way your help will be most useful. When I do reply
I'll also post whatever I learned so that anybody else following this post,
perhaps another newbie like me, may also benefit.

Thanks again, Ted.

Rich Hollenbeck

"Ted Allen" <[email protected]>

wrote
in message

Hi Richard,

It sounds like you could probably use subqueries or
domain aggregate functions to do what you want to do,
rather than having nested queries. Sometimes I find this
easier to deal with because I can see everything at once.

I'm not sure, but from reading your example it sounds
like you would also have the option of using domain
aggregate functions inside your report directly if you
want to keep the query simple.

Domain aggregate functions can be very useful when
combined with your field values. For example, you could
use DSum() to return the sum of all activity weights with
a GroupID matching the current activity. The key of
course is to be able to properly concatenate the criteria
condition which limits the domain.

Calculating the summary values in the query has some
advantages. One big advantage is that the query can
easily be used for other forms or reports in the future.
On the other hand, calculating the values in the report
makes it a little easier to see how each particular value
is being calculated (and it is easy to copy the formulas
to fields in other forms and/or reports if needed).

Personally I try to avoid doing things like this in VBA,
because in my working environment if I ever leave it is
very unlikely that my replacement will be able to figure
out what I was doing.

This is all general info. Hopefully it will help give
you some insight. If you have any specific

questions
on

how to use domain aggregate functions or subqueries for
your situation, it would probably be a good idea to post
back with a specific example of a single calculation
formula, and the field values involved (as well as their
table relationships if they come from multiple tables).

HTH, Ted Allen
-----Original Message-----
I have a big mess on my hands. I've been making many
work-around to a
flawed set of queries I made and now it's finally back
to the drawing board.
I made a few changes and now I can't figure out why it
quit working. The
problem is that my mess is now so big that I don't know
where to start over.
I don't want to go back to a saved backup. I have
several saved queries,
each built on each other, that a report is based on.
Each saved query is in
excess of ten lines of code. It's way too complicated
to troubleshoot and
I'd like to start over. I'd like to avoid saved queries
altogether and
create a DAO.database and DAO.recordset based on

one
big

StrSQL statement
inside the report's module. then assign some of the
values to textboxes
and/or labels within the report.

The report displays any and/or all students' grades in a
course for each
activity in that course (one page per student). The
activities are grouped
by "groups." The activities each have a weight within
that group and the
groups have a weight within each course. For example,
the final exam may be
worth 45% of the group "exams." and the "exams" group
may be worth 20% of
the total grade in that course. The 45%, in this
example, would be the
[activities].[activityWeight] and the 20% in the same
example would be the
[groups].[groupWeight]. The activity percentage weight
would be the current
activity's weight divided by the sum of all
activityWeights within that
group times that group's groupWeight. Brrrr! I get
confused just
describing my situation.

So I need to show [courses].[courseCode], [courses].
[courseDescription],
[groups.groupID], [groups].[groupDescription], [groups].
[groupWeight],
[activities].[activityID], [activities].
[activityDescription],
[activities].[activityWeight], [students]. [studentName],
[students].[StudentID], and [studentScores].

[score].
So

far, that's pretty
easy. I can do that easily either by writing the SQL
code directly or by
using the QBE tool.

***** But ***** within each group, I also need to
calculate the group's
weight against its percentage of the entire course's
group weights and the
same with the activity weight as a percentage of

the
sum

of activity
weights within each group. Once I get these summary
figures I can plug the
results into text boxes or labels in the report, grouped
by each student
within each course.

The first time I tried this I made a query that got the
summary infomation
and saved it as a query. Then I made another query to
gather the other
information I needed and also referenced the first query
to get the
summaries. I also did this second query in the QBE.

There has GOT to be a better way. Upon request I will
cheerfully post all
the queries involved in the original report. I'm
thinking about starting
from scratch.

Should I make subqueries in the main query to get the
summary data instead
of referencing an existing query in the QBE? Can I do
all this inside the
report's module? Do I need saved queries at all?

If
I

had it in the module
would I use DAO (I think I prefer it over ADO)?
I know this sounds confusing. It's even more confusing
when you see how I
made it work before. I had to divide some numbers by
100 and 1000 and other
numbers I had to multiply by ten or 100, etc., just to
make the numbers
calculate correctly. It got really crazy. I was never
sure which query I
needed to modify. I'm looking forward to a simpler
approach.

Many thanks for any suggestions. . .

Rich Hollenbeck


.



.

.