With the help of previous posts to my question this exactly where
I am now.
OK, here are the results of the query I need to feed my reports.
Twirler Scoresheet
Mary B Strut
Mary B Solo
Mary B 2 Baton
Mary B Modeling
Jane C Modeling
Jane C X Strut
Jane C Solo
Jane C 2 Baton
Each score sheet is a seperate report since each event is scored
on different techniques/skills.
I need all the score sheets for each person printed in the
sequence shown above. The only way I can see to do this is to
open the required report for one score sheet, get the twirlers
name into the correct text box, print the report, and go on to the
next twirler.
Ideas???
It's really a matter of getting the right data in the report's
recordsource such that:
1. you can select on the right data, AND
2. you can sort and group in the appropriate order.
I don't know enough about your data to determine what will work, but
one option would be to use your existing report as a subreport of
another report that uses as its RecordSource the SQL you were
previously using in your recordset. This can cause problems if each
individual report spans multiple pages, but you don't say they
aren't 1-page reports, so it might not be an issue.
Again, this is the traditional
Yes I am. I Took my first programming class (Frotran) in 1970.
Worked on a very large payroll/finance system in the late 70/early
80s for the USMC (written in Assembler). Taught Fortran, COBOL,
PL1, Assembler at the Junior college level. Have a degree in
Computer Science from the University of California Irvine. Old
dogs can learn new tricks.
Of course they can, but they have to know the lay of the land to
suspect what tricks are out there. I think that using Access
interactively is the best way to get started with that.
make things harder than they need to be, because they
exactly what do you mean 'interactively'? using the Wizards? or
the design views of objects?
Yes. This teaches you the default methods for accomplishing things
without coding (or with minimal code created by the wizards). The
ideal is to do as much interactively and only delve into code where
required.
Of course, one can very quickly start needing to get into code if
you need to do something more complicated than is possible
interactively, particular when attempting to automate a series of
manual tasks.
The point is that assigned recordsets are something you can use only
in code. Likewise, the first version of Access to even offer the
ability to assign an existing recordset to a form or report was
Access 2000, and all of us Access developers had had many years of
productivity creating complex and rich applications without ever
needing that feature. I still haven't used it except in proof of
concept experiments, and it's been available for 10 years.
