Form to select multiple items from table, then print report

[Tally Ho]

Until recently I had only used Access to manage data for my personal use.
Thanks very much to the knowledge gained here I have successfully designed
my first multi-user Access application. It's almost too successful.

It's pretty simple, a backend with a single table that contains data that I
import from various files:

tblProducts
---------------
id > PK autonum
MfgName
PartNum
Description
ListPrice
CostPrice
etc...

....and a front end distributed to users that contains a form with a combo
box and several text boxes that allows users to filter the table by
manufacturer name, part number, etc, in order to view the desired record(s).

Even users that are computer shy have found the application very useful and
easy to use. The problem is that many of the them are very "paper-centric"
and would like to be able to print "something" for future reference. I can
design a useful report but printing a single record at a time will kill too
many trees. I'd like to enable them to browse and mark multiple records for
later printing at the click of a command button. In my former single-user
world I'd simply add a Yes/No field to the Products table to designate items
to print but I am at a loss as to how to handle this in a multi-user
environment. If someone can offer some assistance or point me to a useful
reference I would be extremely grateful.

Thanks in advance
Steve P.

stevep AT monkey DASH butler DOT net

 

[Albert D.Kallal]

You can always built a table in the "front end" that is just a "list" of
records selected. (a one column table with just a "ID" field). You then use
that for the criteria of the report

docmd.OpenReport "myreprot",acViewPreview,,"ID in (select id from
myLocalTableFrontEnd)"

So, what you do is make a continues form with a button on it..and when you
click on that button, you add the record "ID" to the front end table. You
then use a standard/legal "where" clause when you open the report as above.
Since each user has their own front end...no conflicts. You could even bind
this table to a query that is connected to the back end table..and then use
your check box idea.

However, I do have a more cool approach..and that is to use a un-bound check
box on a continues form....

Check out the example I have here:
http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html
Grab the multi-select example...


And, for some screen shots of forms with buttons in continues mode..take a
look here:
http://www.members.shaw.ca/AlbertKallal/Articles/Grid.htm

 

[Tally Ho]

Thanks, good answer! I wasn't thinking in the "front end is unique to each
user" mode. I
have played with the first approach and it seems to be doable within my
limited skill set. Your "Cool" approach is intriguing but I suspect that it
would not be appropriate for me as the users are allowed to change the
filter property of the form during their selection process?

 

[Albert D.Kallal]

Thanks, good answer! I wasn't thinking in the "front end is unique to
each
user" mode. I
have played with the first approach and it seems to be doable within my
limited skill set. Your "Cool" approach is intriguing but I suspect that
it
would not be appropriate for me as the users are allowed to change the
filter property of the form during their selection process?

Well, hum..it should work, but I think you might get a confusing UI, as the
user could have some difficult knowing what records have been selected.
However, if the form is NOT exited..then I don't see why my approach would
not work. That code simply builds up a "collection" of key id values
selected....