Variables out the wazoo...

G

Guest

I've got a report that captures the following information...
("---->" indicates sub-grouping)

[Location]
------>--[testType] Can be one of several test types, where similar test
types are
grouped together. This can be either [xx], [y1], [y2],
[yInfinity] where all
the [xx] test types would be combined, and all the [y_] test types
would be
combined.... Each would be averaged separately from one another,
and
then the two averages would be averaged together. This field is
tied directly
to a table.

Here's the catch.... the [y_] test types can come in batches of
varying
amounts. These batches are based on dates. Therefore, the
batches
can contain any number of samples. These samples are batched
together
based on a sample collection date. In essence, the batches are
combined
to equal one test.

[testResults] of each test type, that should be grouped together,
are then
averaged, resulting in a daily average for each test type.
Again, there can
can be multiple (an unlimited number) results for similar test
types. This
is the average of the [xx] test types, and the average of the
[y_] test types,
averaged separately. Again, this field is tied directly to a
table.

[dailyAverages] of each test type are then averaged together, to
give a
monthly average, for the location. This is an unbound field.


--------------> Monthly average - the results of the multiple averages per
location as defined in the Test Type area above. This too, is an unbound
field.
----------------------------------------------------------------------------------------------
Right now I'm trying to group everything with IIf statements, but that is
not working. How can I separately combine the different test types,
accounting for the batches, prior to averaging them together, and then loop
back to grab those results and then average the averaged results together,
per location.... completely independent of other locations? Any help on this
isse will be greatly appreciated.
 
L

Larry Daugherty

While you may be working toward the concept of a report I don't
believe you are using the Access Report Designer. You'll get to it by
opening Database|Reports, clicking on the New command button and away
you go.

If you were using the Report Designer you'd find all kinds of features
such as Sorting and Grouping that would ease your life considerably.

You'll find it easy to handle any number of "x" or "y" entries and to
determine the mean for each in the footer of its group.

You write "This field is tied directly to a table.". Huh? Are you
struggling in Access or in Excel or some other application/platform?
In Access, reports receive data from queries. But you are talking
about a calculated value and referring to being tied to a field. I
suspect that you are storing calculated data in a table in your
database. That just should not be done in a relational database.

In short, if you are using Access and you use the Report Designer and
appropriate queries then if your data design is correct you can report
to any level of complexity or granularity.

To get more specific answers you'd have to post your issues with your
data design spelled out in detail.

HTH
--
-Larry-
--

Joshua K Briley said:
I've got a report that captures the following information...
("---->" indicates sub-grouping)

[Location]
------>--[testType] Can be one of several test types, where similar test
types are
grouped together. This can be either [xx], [y1], [y2],
[yInfinity] where all
the [xx] test types would be combined, and all the [y_] test types
would be
combined.... Each would be averaged separately from one another,
and
then the two averages would be averaged together. This field is
tied directly
to a table.

Here's the catch.... the [y_] test types can come in batches of
varying
amounts. These batches are based on dates. Therefore, the
batches
can contain any number of samples. These samples are batched
together
based on a sample collection date. In essence, the batches are
combined
to equal one test.

[testResults] of each test type, that should be grouped together,
are then
averaged, resulting in a daily average for each test type.
Again, there can
can be multiple (an unlimited number) results for similar test
types. This
is the average of the [xx] test types, and the average of the
[y_] test types,
averaged separately. Again, this field is tied directly to a
table.

[dailyAverages] of each test type are then averaged together, to
give a
monthly average, for the location. This is an unbound field.


--------------> Monthly average - the results of the multiple averages per
location as defined in the Test Type area above. This too, is an unbound
field.
--------------------------------------------------------------------
--------------------------
Right now I'm trying to group everything with IIf statements, but that is
not working. How can I separately combine the different test types,
accounting for the batches, prior to averaging them together, and then loop
back to grab those results and then average the averaged results together,
per location.... completely independent of other locations? Any help on this
isse will be greatly appreciated.
 
G

Guest

Larry,

Apparently we're getting caught up in semantics here. Yes, of course the
field is associated with a query... which is associated with a table. In an
effort to minimize my statement, I chose to eliminate the obvious
information. The issue at hand is an issue of logic that a programmer
(which I'm not) may help me better understand.

And to answer your question:
"Are you struggling in Access or in Excel or some other application/platform?"

This is an Access programming forum, right?


Somecallmejosh


Larry Daugherty said:
While you may be working toward the concept of a report I don't
believe you are using the Access Report Designer. You'll get to it by
opening Database|Reports, clicking on the New command button and away
you go.

If you were using the Report Designer you'd find all kinds of features
such as Sorting and Grouping that would ease your life considerably.

You'll find it easy to handle any number of "x" or "y" entries and to
determine the mean for each in the footer of its group.

You write "This field is tied directly to a table.". Huh? Are you
struggling in Access or in Excel or some other application/platform?
In Access, reports receive data from queries. But you are talking
about a calculated value and referring to being tied to a field. I
suspect that you are storing calculated data in a table in your
database. That just should not be done in a relational database.

In short, if you are using Access and you use the Report Designer and
appropriate queries then if your data design is correct you can report
to any level of complexity or granularity.

To get more specific answers you'd have to post your issues with your
data design spelled out in detail.

HTH
--
-Larry-
--

Joshua K Briley said:
I've got a report that captures the following information...
("---->" indicates sub-grouping)

[Location]
------>--[testType] Can be one of several test types, where similar test
types are
grouped together. This can be either [xx], [y1], [y2],
[yInfinity] where all
the [xx] test types would be combined, and all the [y_] test types
would be
combined.... Each would be averaged separately from one another,
and
then the two averages would be averaged together. This field is
tied directly
to a table.

Here's the catch.... the [y_] test types can come in batches of
varying
amounts. These batches are based on dates. Therefore, the
batches
can contain any number of samples. These samples are batched
together
based on a sample collection date. In essence, the batches are
combined
to equal one test.

[testResults] of each test type, that should be grouped together,
are then
averaged, resulting in a daily average for each test type.
Again, there can
can be multiple (an unlimited number) results for similar test
types. This
is the average of the [xx] test types, and the average of the
[y_] test types,
averaged separately. Again, this field is tied directly to a
table.

[dailyAverages] of each test type are then averaged together, to
give a
monthly average, for the location. This is an unbound field.


--------------> Monthly average - the results of the multiple averages per
location as defined in the Test Type area above. This too, is an unbound
field.
--------------------------------------------------------------------
--------------------------
Right now I'm trying to group everything with IIf statements, but that is
not working. How can I separately combine the different test types,
accounting for the batches, prior to averaging them together, and then loop
back to grab those results and then average the averaged results together,
per location.... completely independent of other locations? Any help on this
isse will be greatly appreciated.
 
L

Larry Daugherty

The HTH above my name at the end of my responses is an acronym for
"Hope This Helps". "Helps", not "hurts" or "hinders" or "harms your
self esteem".

I asked the questions because I wanted to know. The knowledge to be
communicated in the answers would help in addressing the issues. Very
little is so obvious that it doesn't require stating or verification.
Have you ever looked at the witty parse of ASSUME? ASS-U-ME

Semantics are important. Review the definitions of semantics and
you'll see that it isn't just a put-down. Nomenclature and
terminology and jargon are required in order to communicate
efficiently and effectively. Some rigor is required. Otherwise we're
continually placing the burden of inferring our meanings on the
recipient. "That thingie over there" doesn't communicate much when we
have to rely on just the written/printed word.

We Software Engineers used to sneer at mere programmers. Now the
lines are blurred and, sure enough, I'm a programmer (on my good
days).

You didn't answer the "Access, Excel or other ..." question. You
simply responded with another question which you seem to think
constitutes a self evident truth. How wrong can you be? Lurk the
Access newsgroups thoroughly for a week. Count the posts that have
nothing to do with MS Access. One MVP has a script that he can hotkey
into his responses that advises folks that they have posted into an
Access newsgroup and that they should post into a newsgroup devoted to
their application instead.

I'm not interested in pissing contests. My response to your post was
a sincere attempt to help you. That you chose to interpret it as an
attack on you is your business.

Just think, if you had responded to the questions with pertinent
answers you might already have had more useful information in hand and
be well on the way to solving your problems. I would rather that
outcome. That's what I'm here for.

You have lots of options toward finding solutions. Just a few among
them: you can continue this thread with answers you choose to give and
I or someone else will pick up the thread and try to help you. You
can break out of this thread and start a new one. In that case, I'll
try to have the presence of mind not to get involved. Same thing goes
in that you can start another thread in a different Access newsgroup.
Since you expressed that your issue was with a report you might try
microsoft.public.access.reports

What ever you decide, Good Luck.

HTH
--
-Larry-
--

Joshua K Briley said:
Larry,

Apparently we're getting caught up in semantics here. Yes, of course the
field is associated with a query... which is associated with a table. In an
effort to minimize my statement, I chose to eliminate the obvious
information. The issue at hand is an issue of logic that a programmer
(which I'm not) may help me better understand.

And to answer your question:
"Are you struggling in Access or in Excel or some other application/platform?"

This is an Access programming forum, right?


Somecallmejosh


Larry Daugherty said:
While you may be working toward the concept of a report I don't
believe you are using the Access Report Designer. You'll get to it by
opening Database|Reports, clicking on the New command button and away
you go.

If you were using the Report Designer you'd find all kinds of features
such as Sorting and Grouping that would ease your life considerably.

You'll find it easy to handle any number of "x" or "y" entries and to
determine the mean for each in the footer of its group.

You write "This field is tied directly to a table.". Huh? Are you
struggling in Access or in Excel or some other application/platform?
In Access, reports receive data from queries. But you are talking
about a calculated value and referring to being tied to a field. I
suspect that you are storing calculated data in a table in your
database. That just should not be done in a relational database.

In short, if you are using Access and you use the Report Designer and
appropriate queries then if your data design is correct you can report
to any level of complexity or granularity.

To get more specific answers you'd have to post your issues with your
data design spelled out in detail.

HTH
--
-Larry-
--

message news:[email protected]...
I've got a report that captures the following information...
("---->" indicates sub-grouping)

[Location]
------>--[testType] Can be one of several test types, where
similar
test
types are
grouped together. This can be either [xx], [y1], [y2],
[yInfinity] where all
the [xx] test types would be combined, and all the
[y_]
test types
would be
combined.... Each would be averaged separately from
one
another,
and
then the two averages would be averaged together.
This
field is
tied directly
to a table.

Here's the catch.... the [y_] test types can come in batches of
varying
amounts. These batches are based on dates.
Therefore,
the
batches
can contain any number of samples. These samples are batched
together
based on a sample collection date. In essence, the batches are
combined
to equal one test.

[testResults] of each test type, that should be
grouped
together,
are then
averaged, resulting in a daily average for each test type.
Again, there can
can be multiple (an unlimited number) results for
similar
test
types. This
is the average of the [xx] test types, and the
average of
the
[y_] test types,
averaged separately. Again, this field is tied
directly
to a
table.

[dailyAverages] of each test type are then averaged together, to
give a
monthly average, for the location. This is an unbound field.


--------------> Monthly average - the results of the multiple averages per
location as defined in the Test Type area above. This too, is
an
unbound
-------------------------------------------------------------------- but
that is
not working. How can I separately combine the different test types,
accounting for the batches, prior to averaging them together,
and
then loop
back to grab those results and then average the averaged results together,
per location.... completely independent of other locations? Any help on this
isse will be greatly appreciated.
 
G

Guest

Sorry to offend.
--
Somecallmejosh


Larry Daugherty said:
The HTH above my name at the end of my responses is an acronym for
"Hope This Helps". "Helps", not "hurts" or "hinders" or "harms your
self esteem".

I asked the questions because I wanted to know. The knowledge to be
communicated in the answers would help in addressing the issues. Very
little is so obvious that it doesn't require stating or verification.
Have you ever looked at the witty parse of ASSUME? ASS-U-ME

Semantics are important. Review the definitions of semantics and
you'll see that it isn't just a put-down. Nomenclature and
terminology and jargon are required in order to communicate
efficiently and effectively. Some rigor is required. Otherwise we're
continually placing the burden of inferring our meanings on the
recipient. "That thingie over there" doesn't communicate much when we
have to rely on just the written/printed word.

We Software Engineers used to sneer at mere programmers. Now the
lines are blurred and, sure enough, I'm a programmer (on my good
days).

You didn't answer the "Access, Excel or other ..." question. You
simply responded with another question which you seem to think
constitutes a self evident truth. How wrong can you be? Lurk the
Access newsgroups thoroughly for a week. Count the posts that have
nothing to do with MS Access. One MVP has a script that he can hotkey
into his responses that advises folks that they have posted into an
Access newsgroup and that they should post into a newsgroup devoted to
their application instead.

I'm not interested in pissing contests. My response to your post was
a sincere attempt to help you. That you chose to interpret it as an
attack on you is your business.

Just think, if you had responded to the questions with pertinent
answers you might already have had more useful information in hand and
be well on the way to solving your problems. I would rather that
outcome. That's what I'm here for.

You have lots of options toward finding solutions. Just a few among
them: you can continue this thread with answers you choose to give and
I or someone else will pick up the thread and try to help you. You
can break out of this thread and start a new one. In that case, I'll
try to have the presence of mind not to get involved. Same thing goes
in that you can start another thread in a different Access newsgroup.
Since you expressed that your issue was with a report you might try
microsoft.public.access.reports

What ever you decide, Good Luck.

HTH
--
-Larry-
--

Joshua K Briley said:
Larry,

Apparently we're getting caught up in semantics here. Yes, of course the
field is associated with a query... which is associated with a table. In an
effort to minimize my statement, I chose to eliminate the obvious
information. The issue at hand is an issue of logic that a programmer
(which I'm not) may help me better understand.

And to answer your question:
"Are you struggling in Access or in Excel or some other application/platform?"

This is an Access programming forum, right?


Somecallmejosh


Larry Daugherty said:
While you may be working toward the concept of a report I don't
believe you are using the Access Report Designer. You'll get to it by
opening Database|Reports, clicking on the New command button and away
you go.

If you were using the Report Designer you'd find all kinds of features
such as Sorting and Grouping that would ease your life considerably.

You'll find it easy to handle any number of "x" or "y" entries and to
determine the mean for each in the footer of its group.

You write "This field is tied directly to a table.". Huh? Are you
struggling in Access or in Excel or some other application/platform?
In Access, reports receive data from queries. But you are talking
about a calculated value and referring to being tied to a field. I
suspect that you are storing calculated data in a table in your
database. That just should not be done in a relational database.

In short, if you are using Access and you use the Report Designer and
appropriate queries then if your data design is correct you can report
to any level of complexity or granularity.

To get more specific answers you'd have to post your issues with your
data design spelled out in detail.

HTH
--
-Larry-
--

message I've got a report that captures the following information...
("---->" indicates sub-grouping)

[Location]
------>--[testType] Can be one of several test types, where similar
test
types are
grouped together. This can be either [xx], [y1], [y2],
[yInfinity] where all
the [xx] test types would be combined, and all the [y_]
test types
would be
combined.... Each would be averaged separately from one
another,
and
then the two averages would be averaged together. This
field is
tied directly
to a table.

Here's the catch.... the [y_] test types can come in
batches of
varying
amounts. These batches are based on dates. Therefore,
the
batches
can contain any number of samples. These samples are
batched
together
based on a sample collection date. In essence, the
batches are
combined
to equal one test.

[testResults] of each test type, that should be grouped
together,
are then
averaged, resulting in a daily average for each test
type.
Again, there can
can be multiple (an unlimited number) results for similar
test
types. This
is the average of the [xx] test types, and the average of
the
[y_] test types,
averaged separately. Again, this field is tied directly
to a
table.

[dailyAverages] of each test type are then averaged
together, to
give a
monthly average, for the location. This is an unbound
field.


--------------> Monthly average - the results of the multiple
averages per
location as defined in the Test Type area above. This too, is an
unbound
field.
--------------------------------------------------------------------
--------------------------
Right now I'm trying to group everything with IIf statements, but
that is
not working. How can I separately combine the different test types,
accounting for the batches, prior to averaging them together, and
then loop
back to grab those results and then average the averaged results
together,
per location.... completely independent of other locations? Any
help on this
isse will be greatly appreciated.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top