Re: Variables out the wazoo...

Sorry to offend.
--
Somecallmejosh


"Larry Daugherty" wrote:

> 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" <JoshuaKBriley@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> message news:3AF5FF32-4895-43F8-ADEE-8A6CE820FE6A@xxxxxxxxxxxxxxxx
> > 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" wrote:
> >
> > > 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" <JoshuaKBriley@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote
> in
> > > message news:847EB15C-0D71-46F1-8CB7-02EB0D91C1AB@xxxxxxxxxxxxxxxx
> > > > 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.
> > > >
> > > > --
> > > > Somecallmejosh
> > >
> > >
> > >
>
>
>
.