Adding Multiple rows at a time

  • Thread starter Thread starter Slider
  • Start date Start date
S

Slider

Hi

The situation is this. I am trying to create a way in which to record
attendance.

I have a table with a list of people called somewhat cryptically LPO (I
did not create the existing database) which contains around 200
records. Attendance for the people in this table has to be marked every
day.

What I want to do is create a form that prompts the user for a date,
then displays a list of these people, the date selected and a field to
record present/not present. I want the user to be able to enter
attendance information for each of these records and record this in
another table (called say "Attendance")

My problem is this. I am able to get this working fine for one "person"
record at a time. However, when I attempt to get it working at
described above I run into two problems.

Firstly, when I create a form that displays all the "person" records
along with fields to record attendance, a change in one of the
"attendance" fields changes all attendance fields.

Secondly, I have yet to find a way to add multiple records at the one
time. What I would ideally like to happen is for the user to enter the
information for all of the records then click an "add all" button at
the bottom that would add all of the records to the table. Currently
all I can seem to do is add one record at a time.

Is what I am after possible in Access or am I going about the problem
all wrong?

Thanks for your help
 
Another approach to what you are describing would be a pair of listboxes.
One listbox would contain all possible attendees who were NOT in attendance
on a given date. The other listbox would contain all attendees who WERE in
attendance.

There are several examples of this in the wizards Access offers.

Conceptually, you are filling the "possibles" listbox from a list of the
people who are NOT in your attendance table for the date. You are filling
the "attending" listbox from the people who ARE in your attendance table for
the date. You are allowing multiple selections in the "possibles" box, and
presenting a button to indicate <Attended>.

If you add a date field on the form, you can select/enter a date, select
those who attended and click your <Attended> button, and, as part of the
code behind the <Attended> button, refresh the listbox lists.

Definitely more than casual programming, but no rocket science...<g>
 
Thanks Jeff

What I've actually ended up doing (after having another crack at it
this morning) is as follows.

User opens a form which allows them to pick a date, then clicks a
button which launches a macro.

The macro first runs an append table query which basically creates a
new entry in the attendance table for all possible attendees for that
date.

It then opens a form in a datasheet view that is based on a query
pulling out all the entries from the attendance table for that date.

The user is then able to use a checkbox to indicate present/not
present, and simply close down the form when they are finished. All
records are of course saved when they do this.

This approach certainly has some dissadvantages, especially in
presentation, but I'm working on those.

Do you see any glaring holes in this approach that I may have
overlooked?

Thanks
 
If you are saying that you are filling a table with "dummy" attendees, and
checking only those that actually attended, you'd be storing useless (and
potentially confusing) records.

Or did I misunderstand?
 
Hello!

PMFJI...

Jeff, I have created a small program to track attendance in my classes. I
use a system similar in general concept to that created by Slider. I wonder
if "useless" would be correct with respect to the "dummy" attendees. Could
there possibly be value in knowing that someone didn't attend a class? In
other words, for all my students for a class on a given day, I need to know
if they attended or not; thus, I need a record indicating attendance for
every student. I suppose I might be able to derive this by querying for
nulls, however. Still, it seems reasonable to me, or am I misguided?

In addition, just to expand the discussion, I like this approach because
tracking attendance (at least for me, and I know that the OP didn't specify
this!) involves more than just being present/absent. In my record keeping I
record 4 states: Present, Late, Absent (i.e. known excused absence), Unknown
(unexcused absence or, I suppose.. teacher failed to mark attendance <g>). I
can do this by creating a "dummy" record for each student, set to "Unknown"
as the default value.

I *do* appreciate the ease of data entry that this approach affords me: I
press a button, and the just check the appropriate value for each student.
However, I'd be happy to get any suggestions that might indicate a better
approach!

Cheers!
Fred Boer

P.S. I just *love* the concept of "dummy" attendees! Not that any of my
students would qualify.. ;)
 
Yah! I carefully chose my terminology. As a recovering Statistics
instructor, precision counts <g>.

The only reason I can imagine for storing a dummy record of attendee (i.e.,
someone who wasn't there) is if there's a chance I missed someone in taking
attendance, and I would later want to check them off. However, there are
other ways to handle this, without resorting to putting what amounts to
bogus records in the table.

Now, to the point of determining who did NOT attend a particular class
session. I'd be inclined (yes, some folks call me 'bent') to use a query
that, for a given class session, finds registered students who were NOT in
the table for that class session. Registered students would come from
another table that keeps a (single) list of everyone who signed up for the
"class".

From an esthetic/elegance standpoint, I don't see a reason to store dummies,
just to make using a form easier (but then, I'm something of a data bigot).

An alternate approach to "checking off" attendance for a class session can
be found up-thread. I'd probably use paired listboxes to generate the
append/insert operations for attendees. My (roman/latin, left-to-right)
approach would put a list (box) of registered students on the left, a list
(box) of (registered) students attending on the right, a way to shift
students back/forth (command buttons, which added/removed students from the
"attended" box), and a way to specify class/session/date/time on the form.

But that's JOPO (just one person's opinion)
 
Jeff, Fred

I somewhat simplified my situation in my question. I may have over
simplfied.

I am tracking the attendance of traders accross several different
markets. Attendance checks may take place twice daily, daily, or
sporadically depending on the traders market. The checks themselves may
not take place every time they are scheduled due to time contraints. In
each check, a trader may be present/not present, trading/not trading
(i.e. there are 3 states: present and trading, not present and trading
(someone else is working for the trader), not present and not trading
(no one is there)).

So basically, I can't just assume that checks have taken place when
they are supposed to be

I need to keep track of when the checks take place, and what state
traders were in at that time.
 
Dear Jeff.. and Slider!:

Well, I am always interested in learning the correct/best way to do things,
so if you don't mind some follow-up...

I understand what you are suggesting, Jeff, about the use of paired
listboxes. I have created an application that uses multi-select paired
listboxes. But... let's assume that I want to be a data bigot, too <g>. What
would you suggest to manage the situation I described, where it isn't simply
a yes/no, but where there are multiple values for attendance? Or am I
missing the point?

I appreciate you taking the time to discuss this!

Cheers!
Fred
 
Fred

Clearly, I hadn't had enough caffeine this morning when I responded. If
your situation requires assigning a status to every registered individual,
you'll need to load them all in, sooner or later.

I was considering only a "present/absent" determination.

Regards

Jeff Boyce
<Office/Access MVP>
 
Thanks, Jeff!

Fred

Jeff Boyce said:
Fred

Clearly, I hadn't had enough caffeine this morning when I responded. If
your situation requires assigning a status to every registered individual,
you'll need to load them all in, sooner or later.

I was considering only a "present/absent" determination.

Regards

Jeff Boyce
<Office/Access MVP>
 
Back
Top