To solve this in the past I wrote such data to a temporary table, produced
a
report from a query on that table, then deleted the table. There has to
be
an easier way.
I would be hard pressed to come up with a easier way then the above.
Just write out the "id" (primary key - "PK") to a table. then, to printout
those records, just build a query that
does a join from the "id" you write out to this table. Once you build that
query, then
run your code (can even be run as a scheduled batch at night)
this code would write out the id's to a that temp table
run your report
you are done.
I can't really imagine anything be less work or "has to be an easier way".
So, you don't have to write out the whole data table..but just the "id" that
you need, or want to check....
Note that you don't even have to build that left join query, but in fact can
launch ANY report you have that has a (PK) id in it, and restrict it to that
list you made in the table.
so, you would clear out that table (don't need to delete it)
currentdb.Execute "delete * from tblBadReocrds"
' your processing code to write out id's to above one column table.
here how the code would launch ANY report in your appcation, but RESTRICT it
to that temp table of ID's you created.
dim strWhere as string
strWhere = "ID in (select BadID from tblBadReocrds)"
docmd.OpenReport "Customers",acViewPreview,,strWhere
So, you can "pass" that list of id's to any report (and, the above works
with a form also).
I guess I made this post a bit longer then usually, as I wanted to convey a
"mind set" change from those older mainframe days when you would writing
looping code etc to output data to a printer. In modern systems, we use sql
to accomplish that type of looping. So, many data processing solutions tend
to be build around the ability of reports and forms to consume sql, or as
above shows a "where" clause that is legitimate sql. The results of the
above means we don't have to code, or write code for the output of our data,
but simply "feed" that list of bad id to the report (or form) that we want
to display our data with.
I suppose your processing code could open up a temp text file, and when done
you send that to the printer. However, you would not have any type of
formatting etc, but would just be printing a text file. (you would launch
notepad..and print that). So, the above outlined solution is far more
flexible, as once you built your table of bad id's, then you can use the
above code snip to launch any report you have in the system now.
if you plan to run your application in a multi-user environ, then users
would actually trip over each other when they use the temp table. However,
the simple solution is to place the temp table in the front end, so each
user gets their own copy. This would assume you split your database.
You can read about spitting here:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm