| Author |
Message |
|
Ray Marti
#1 / 11
|
 Attendance I need some inspriation for keeping attendance history for the classroom. I already have a database of student information including advisors.
I can't mentally leap to a way to keep "P," "A," and "T" for each student,
for each day.
Has anybody already invented this wheel?
P.S. I'm still in 4.1
Thanks in advance.
|
| Wed, 05 Nov 2003 01:16:52 GMT |
|
 |
|
Jame
#2 / 11
|
Attendance Hi Ray - This wheel has been invented many times and there are a variety of
approaches. One that I like is to use a database of attendances, related to
the database of students. Each record in this database would have a field for
StudentID, Date, and AttendanceStatus. Then, a scrolling portal in the
database of students can show an attendance history for that student, and many
useful attendance reports can be generated from the database of attendances.
If you go a step further, and start trying to track attendance per student per
date per CLASS, things get much more interesting. This many-to-many
relational model is one of the group's favorite bones of contention, and some
really great ideas have been put forth. A search of the group's archive
(perhaps on the subject "many-to-many") will take you to some of the threads.
Best of Luck -
James
Quote:
> I need some inspriation for keeping attendance history for the classroom. > I already have a database of student information including advisors.
> I can't mentally leap to a way to keep "P," "A," and "T" for each student,
> for each day.
> Has anybody already invented this wheel?
> P.S. I'm still in 4.1
> Thanks in advance.
-- Don't forget to remove the obvious spam block when replying. I advocate making an address book entry and using it! Thanks!
|
| Wed, 05 Nov 2003 01:45:07 GMT |
|
|
|
John Weinshe
#3 / 11
|
Attendance To record attendance for a student for every day, you need a second related file ("Days") with one record for every day for every student. You obviously want to keep this second file small, as it will quickly contain a zillion records. It really only needs the Student ID, date, and a "PAT" field, although you can add a name field, time of arrival (for tardies), etc. If you are uncertain how to build a related file, and, most likely, display
it as a portal in the main file, let us know and we will walk you through
it.
--
John Weinshel
Datagrace
Associate Member, Filemaker Solutions Alliance
Vashon Island, WA
(206) 463-1634
Quote: > I need some inspriation for keeping attendance history for the classroom. > I already have a database of student information including advisors.
> I can't mentally leap to a way to keep "P," "A," and "T" for each student,
> for each day.
> Has anybody already invented this wheel?
> P.S. I'm still in 4.1
> Thanks in advance.
|
| Wed, 05 Nov 2003 01:45:50 GMT |
|
|
|
Ray Marti
#4 / 11
|
Attendance Thanks for the suggestions. I'm already experimenting with a related file. But what's got me intrigued is your mention of the "Archives." Where are they, how do I access them?
Quote: > Hi Ray - > This wheel has been invented many times and there are a variety of
> approaches. One that I like is to use a database of attendances, related
to
> the database of students. Each record in this database would have a field
for
> StudentID, Date, and AttendanceStatus. Then, a scrolling portal in the
> database of students can show an attendance history for that student, and
many
> useful attendance reports can be generated from the database of
attendances.
> If you go a step further, and start trying to track attendance per student
per
> date per CLASS, things get much more interesting. This many-to-many
> relational model is one of the group's favorite bones of contention, and
some
> really great ideas have been put forth. A search of the group's archive
> (perhaps on the subject "many-to-many") will take you to some of the
threads.
> Best of Luck -
> James
> > I need some inspriation for keeping attendance history for the
classroom.
> > I already have a database of student information including advisors.
> > I can't mentally leap to a way to keep "P," "A," and "T" for each
student,
> > for each day.
> > Has anybody already invented this wheel?
> > P.S. I'm still in 4.1
> > Thanks in advance.
> --
> Don't forget to remove the obvious spam block when replying.
> I advocate making an address book entry and using it! Thanks!
|
| Wed, 05 Nov 2003 04:11:07 GMT |
|
|
|
GS
#5 / 11
|
Attendance FileMaker Pro FAQ page: http://heifer.ucc.usyd.edu.au/cdf_faq/ Archive of this newsgroup: http://cdf.filemaker.fm -- Glenn Schwandt
Quote: > Thanks for the suggestions. I'm already experimenting with a related file. > But what's got me intrigued is your mention of the "Archives." Where are > they, how do I access them?
> > Hi Ray -
> > This wheel has been invented many times and there are a variety of
> > approaches. One that I like is to use a database of attendances,
related
> to
> > the database of students. Each record in this database would have a
field
> for
> > StudentID, Date, and AttendanceStatus. Then, a scrolling portal in the
> > database of students can show an attendance history for that student,
and
> many
> > useful attendance reports can be generated from the database of
> attendances.
> > If you go a step further, and start trying to track attendance per
student
> per
> > date per CLASS, things get much more interesting. This many-to-many
> > relational model is one of the group's favorite bones of contention,
and
> some
> > really great ideas have been put forth. A search of the group's
archive
> > (perhaps on the subject "many-to-many") will take you to some of the
> threads.
> > Best of Luck -
> > James
> > > I need some inspriation for keeping attendance history for the
> classroom.
> > > I already have a database of student information including advisors.
> > > I can't mentally leap to a way to keep "P," "A," and "T" for each
> student,
> > > for each day.
> > > Has anybody already invented this wheel?
> > > P.S. I'm still in 4.1
> > > Thanks in advance.
> > --
> > Don't forget to remove the obvious spam block when replying.
> > I advocate making an address book entry and using it! Thanks!
|
| Wed, 05 Nov 2003 04:47:21 GMT |
|
|
|
Bridget El
#6 / 11
|
Attendance Hi Ray All the articles posted to any newsgroup in the Usenet are maintained in
an archive. It used to be kept by Deja but has been taken over by Google,
and is currently in the process of being revamped. Last time I checked,
they only had the last few months worth of posting in the searchable
online database but that may have changed. It is still a great resource
and will be even better when they get up to full speed.
<www.groups.google.com>
--
Bridget Eley
Quote:
> Thanks for the suggestions. I'm already experimenting with a related file. > But what's got me intrigued is your mention of the "Archives." Where are > they, how do I access them?
> > Hi Ray -
> > This wheel has been invented many times and there are a variety of
> > approaches. One that I like is to use a database of attendances, related
> to
> > the database of students. Each record in this database would have a field
> for
> > StudentID, Date, and AttendanceStatus. Then, a scrolling portal in the
> > database of students can show an attendance history for that student, and
> many
> > useful attendance reports can be generated from the database of
> attendances.
> > If you go a step further, and start trying to track attendance per student
> per
> > date per CLASS, things get much more interesting. This many-to-many
> > relational model is one of the group's favorite bones of contention, and
> some
> > really great ideas have been put forth. A search of the group's archive
> > (perhaps on the subject "many-to-many") will take you to some of the
> threads.
> > Best of Luck -
> > James
> > > I need some inspriation for keeping attendance history for the
> classroom.
> > > I already have a database of student information including advisors.
> > > I can't mentally leap to a way to keep "P," "A," and "T" for each
> student,
> > > for each day.
> > > Has anybody already invented this wheel?
> > > P.S. I'm still in 4.1
> > > Thanks in advance.
> > --
> > Don't forget to remove the obvious spam block when replying.
> > I advocate making an address book entry and using it! Thanks!
|
| Wed, 05 Nov 2003 05:29:13 GMT |
|
|
|
Ray Marti
#7 / 11
|
Attendance Well, I will need some help. Specifically, can I cause new records to be created from the main file's portal? Can I see which student has which days' attendance recorded, and those that are 'behind?' Will I be using 'Unique' validation to make sure I don't duplicate any one day for any one student? Sorry to be so dense, but I haven't had my breakthrough yet. Also, I need to foolproof it as much as humanly possible, since a group of teachers will be using the database, not me, and I'm not even on site to fix it.
Quote: > To record attendance for a student for every day, you need a second related > file ("Days") with one record for every day for every student. You obviously > want to keep this second file small, as it will quickly contain a zillion > records. It really only needs the Student ID, date, and a "PAT" field, > although you can add a name field, time of arrival (for tardies), etc. > If you are uncertain how to build a related file, and, most likely,
display
> it as a portal in the main file, let us know and we will walk you through
> it.
> --
> John Weinshel
> Datagrace
> Associate Member, Filemaker Solutions Alliance
> Vashon Island, WA
> (206) 463-1634
> > I need some inspriation for keeping attendance history for the
classroom.
> > I already have a database of student information including advisors.
> > I can't mentally leap to a way to keep "P," "A," and "T" for each
student,
> > for each day.
> > Has anybody already invented this wheel?
> > P.S. I'm still in 4.1
> > Thanks in advance.
|
| Thu, 06 Nov 2003 03:56:41 GMT |
|
|
|
John Weinshe
#8 / 11
|
Attendance Portals are designed to facilitate new record creation in the related file. If the main file is called Students, it should have, in addition to the
usual contact information (name, address, etc.) an ID field, which is best
set up as an auto-entered serial number, with 'Prohibit modification of
value' enabled, and validated as unique. If there is some other necessary
and/or useful number attached to the student, such as a School ID number or
a Social Security number, that's fine-- just don't use them for this ID,
which does not need to be displayed.
Create a new file, "Days", with, at least, the fields "Date" (a date field),
"ID" (number), "PAT" (text), and "Constant", a calculation field, returning
a number, and defined as "1" (the number one).
Make Date be auto entered with the creation date. While that will be the
most likely value, the user can modify it as necessary.
Leave ID alone, as it will be entered correctly from the portal. Same with
PAT, as its formatting will be created back in Students.
Constant may not be used immediately, but it's always good practice to have
a Constant field for creating a generic or 'global' relationship.
You can also create name (first and last) fields, making them lookups from
the Students file via a relationship based on the ID, but it is not really
necessary.
Back in Students, create a relationship ("Days_ID") to the Days file, using
the ID field as the match field on both sides. Enable "Allow creation of
related records". This step allows creation of related records through the
portal. When "Allow creation of related records" is enabled, the last row of
a portal will be blank, allowing entry, and entry of valid values into a
field in that portal row will force the creation of a related record (a
record in Days), with the correct value for the match field (i.e., the
correct ID).
I would also enable, in the Relationship dialogue box, "When deleting a
record in this file, also delete related records". That box can be dangerous
to check, but in this case attendance records would make no sense if there
is no basic record of the student.
You might also choose to sort the relationship (that will affect how it will
display in the portal) by date.
Now create the portal, making it as large as necessary, checking "Allow
deletion of portal records". Place the related fields Date and PAT in the
row. You can elaborate and also add a time field. You do not need the ID
field. Create, in Students, a value list for PAT:
Present
Absent
Tardy
and format the field in the portal row with a popup or radio button of that
value list.
That's it. If you select a value from PAT, a new record will be created in
Days, with the student's ID in the ID field, and the creation date in the
Date field.
You can place a button next to the portal for removing a selected portal
row, in case a user makes a mistake (and you can get a little fancier and
add some password protection to control who can add and remove records).
Format the button with "Delete Portal Row"-- it will automatically ask the
user for confirmation.
To track overall attendance for a given student, in Students you can create
calculation fields using the Aggregate functions. With a bit of elaboration,
these can provide the user with a fair picture of the student's attendance
as compared to their classmates. The reason for creating a single record for
every day for every student is just that, that it creates a rich database of
specific information that can be mined quickly.
To avoid duplicating the same date for a given student requires a calc field
using a self-join relationship in Days, and may not be necessary. I'd hold
off on that one, as a sorted portal will quickly display duplicates. But,
yes, it can be done.
--
John Weinshel
Datagrace
Associate Member, Filemaker Solutions Alliance
Vashon Island, WA
(206) 463-1634
Quote: > Well, I will need some help. > Specifically, can I cause new records to be created from the main file's > portal? > Can I see which student has which days' attendance recorded, and those that > are 'behind?' > Will I be using 'Unique' validation to make sure I don't duplicate any one > day for any one student? > Sorry to be so dense, but I haven't had my breakthrough yet. > Also, I need to foolproof it as much as humanly possible, since a group of > teachers will be using the database, not me, and I'm not even on site to fix > it.
> > To record attendance for a student for every day, you need a second
> related
> > file ("Days") with one record for every day for every student. You
> obviously
> > want to keep this second file small, as it will quickly contain a
zillion
> > records. It really only needs the Student ID, date, and a "PAT" field,
> > although you can add a name field, time of arrival (for tardies), etc.
> > If you are uncertain how to build a related file, and, most likely,
> display
> > it as a portal in the main file, let us know and we will walk you
through
> > it.
> > --
> > John Weinshel
> > Datagrace
> > Associate Member, Filemaker Solutions Alliance
> > Vashon Island, WA
> > (206) 463-1634
> > > I need some inspriation for keeping attendance history for the
> classroom.
> > > I already have a database of student information including advisors.
> > > I can't mentally leap to a way to keep "P," "A," and "T" for each
> student,
> > > for each day.
> > > Has anybody already invented this wheel?
> > > P.S. I'm still in 4.1
> > > Thanks in advance.
|
| Thu, 06 Nov 2003 05:26:28 GMT |
|
|
|
Ray Marti
#9 / 11
|
Attendance John, your help has been invaluable thus far. I have a working (yes, Working!) prototype, but as far as extracting
'Absent' vs. 'Present' or 'Tardy,' with Aggregate functions, using
If...Count has turned into another dead end for me. Is Count the wrong
approach? Is IF the wrong approach?
What I'm getting, of course, is TOTAL count per ID, whether P, A, or T,
undifferentiated.
Not related to the problem above, but is there a way to have the blank line
at the bottom of the portal always visible?
I'm only showing five related records at a time, with a scroll bar, of
course, but as the year progresses, the user will have to scroll quite a
ways down to find the blank line for today's input.
I've attached a $100 bill to this e-mail... hope it makes it.
Quote: > Portals are designed to facilitate new record creation in the related file. > If the main file is called Students, it should have, in addition to the
> usual contact information (name, address, etc.) an ID field, which is best
> set up as an auto-entered serial number, with 'Prohibit modification of
> value' enabled, and validated as unique. If there is some other necessary
> and/or useful number attached to the student, such as a School ID number
or
> a Social Security number, that's fine-- just don't use them for this ID,
> which does not need to be displayed.
> Create a new file, "Days", with, at least, the fields "Date" (a date
field),
> "ID" (number), "PAT" (text), and "Constant", a calculation field,
returning
> a number, and defined as "1" (the number one).
> Make Date be auto entered with the creation date. While that will be the
> most likely value, the user can modify it as necessary.
> Leave ID alone, as it will be entered correctly from the portal. Same with
> PAT, as its formatting will be created back in Students.
> Constant may not be used immediately, but it's always good practice to
have
> a Constant field for creating a generic or 'global' relationship.
> You can also create name (first and last) fields, making them lookups from
> the Students file via a relationship based on the ID, but it is not really
> necessary.
> Back in Students, create a relationship ("Days_ID") to the Days file,
using
> the ID field as the match field on both sides. Enable "Allow creation of
> related records". This step allows creation of related records through the
> portal. When "Allow creation of related records" is enabled, the last row
of
> a portal will be blank, allowing entry, and entry of valid values into a
> field in that portal row will force the creation of a related record (a
> record in Days), with the correct value for the match field (i.e., the
> correct ID).
> I would also enable, in the Relationship dialogue box, "When deleting a
> record in this file, also delete related records". That box can be
dangerous
> to check, but in this case attendance records would make no sense if there
> is no basic record of the student.
> You might also choose to sort the relationship (that will affect how it
will
> display in the portal) by date.
> Now create the portal, making it as large as necessary, checking "Allow
> deletion of portal records". Place the related fields Date and PAT in the
> row. You can elaborate and also add a time field. You do not need the ID
> field. Create, in Students, a value list for PAT:
> Present
> Absent
> Tardy
> and format the field in the portal row with a popup or radio button of
that
> value list.
> That's it. If you select a value from PAT, a new record will be created in
> Days, with the student's ID in the ID field, and the creation date in the
> Date field.
> You can place a button next to the portal for removing a selected portal
> row, in case a user makes a mistake (and you can get a little fancier and
> add some password protection to control who can add and remove records).
> Format the button with "Delete Portal Row"-- it will automatically ask the
> user for confirmation.
> To track overall attendance for a given student, in Students you can
create
> calculation fields using the Aggregate functions. With a bit of
elaboration,
> these can provide the user with a fair picture of the student's attendance
> as compared to their classmates. The reason for creating a single record
for
> every day for every student is just that, that it creates a rich database
of
> specific information that can be mined quickly.
> To avoid duplicating the same date for a given student requires a calc
field
> using a self-join relationship in Days, and may not be necessary. I'd hold
> off on that one, as a sorted portal will quickly display duplicates. But,
> yes, it can be done.
> --
> John Weinshel
> Datagrace
> Associate Member, Filemaker Solutions Alliance
> Vashon Island, WA
> (206) 463-1634
> > Well, I will need some help.
> > Specifically, can I cause new records to be created from the main file's
> > portal?
> > Can I see which student has which days' attendance recorded, and those
> that
> > are 'behind?'
> > Will I be using 'Unique' validation to make sure I don't duplicate any
one
> > day for any one student?
> > Sorry to be so dense, but I haven't had my breakthrough yet.
> > Also, I need to foolproof it as much as humanly possible, since a group
of
> > teachers will be using the database, not me, and I'm not even on site to
> fix
> > it.
> > > To record attendance for a student for every day, you need a second
> > related
> > > file ("Days") with one record for every day for every student. You
> > obviously
> > > want to keep this second file small, as it will quickly contain a
> zillion
> > > records. It really only needs the Student ID, date, and a "PAT" field,
> > > although you can add a name field, time of arrival (for tardies), etc.
> > > If you are uncertain how to build a related file, and, most likely,
> > display
> > > it as a portal in the main file, let us know and we will walk you
> through
> > > it.
> > > --
> > > John Weinshel
> > > Datagrace
> > > Associate Member, Filemaker Solutions Alliance
> > > Vashon Island, WA
> > > (206) 463-1634
> > > > I need some inspriation for keeping attendance history for the
> > classroom.
> > > > I already have a database of student information including advisors.
> > > > I can't mentally leap to a way to keep "P," "A," and "T" for each
> > student,
> > > > for each day.
> > > > Has anybody already invented this wheel?
> > > > P.S. I'm still in 4.1
> > > > Thanks in advance.
|
| Thu, 06 Nov 2003 11:33:29 GMT |
|
|
|
John Weinshe
#10 / 11
|
Attendance Yes, the bill made it. To pull out the aggregate values for PAT, you need to build a filtered
relationship, one that will display the selected records, in this case the
records only for that student, and only for the chosen value of PAT
(Present, Absent, or Tardy). Before going further, however, let me say that
most everything from here on out can usually be built in a few different
ways. I happen to like using relationships for a lot of functions that might
just as easily be performed by searches, or by Reports.
Create, in Students, a global text field ("gPAT"), and format it with the
PAT value list, using a pulldown menu. Create a calculation field
("Left_Side"), returning text:
ID & gPAT.
That will be the left side match field for the filtered relationship
("Filtered"). Create a similar field, as the match field, in Days:
ID & PAT.
Do not allow creation of related records, or sort the relationship. It needs
no portal, and sorting only adds unnecessary weight. The calc field
("Total")(returning a number) for the totals is:
Count(Filtered::ID).
If you gPAT on the layout, and Total right next to it, choosing one of the 3
values from the pulldown menu should return a total for that student (the
ID) and that PAT value (gPAT).
Another popular way is to create, in Days, calc fields such as:
Case(PAT="Present", 1) , Case(PAT="Absent", 1), Case(PAT="Tardy", 1) and
count those values (Count() returns values only for non-empty fields). Or
you can use one calc:
Case
(
PAT="Present", 1,
PAT="Absent", 100,
PAT="Tardy", 1000
)
...and then treat the result with some arithmetic (in the Count calc back in
Students) to ferret out the true totals.
The Aggregate functions work across relationships. They cannot be stored,
for that reason, and take no arguments (meaning you can't use calculations
in them). The safest thing to count in an Aggregate function is the foreign
match field (ID in Days), because every record has one. You can also use
Constant, but, because it is a calculation, it might slow things down a bit.
I hope you can see that you can use the same idea to filter for year or
month, or year and month. You can get fancy and slice the view by day of the
week, and also widen it and see data for all students. Again, there are many
other ways of getting at different views of the data.
As for putting the empty row at the top, the best solution (there is no
simple way to move it to the top, although there are some clever tricks that
approximate that) is to remove "Allow creation of related records" from the
relationship definition, and create the related records via a script,
triggered by a button. Another advantage of a script is that it gives you
full control over the process, meaning you can, within the script, check for
duplicates, and do any other work that needs doing. But again, let's go one
step at a time.
I'm glad the prototype is working.
--
John Weinshel
Datagrace
Associate Member, Filemaker Solutions Alliance
Vashon Island, WA
(206) 463-1634
Quote: > John, your help has been invaluable thus far. > I have a working (yes, Working!) prototype, but as far as extracting
> 'Absent' vs. 'Present' or 'Tardy,' with Aggregate functions, using
> If...Count has turned into another dead end for me. Is Count the wrong
> approach? Is IF the wrong approach?
> What I'm getting, of course, is TOTAL count per ID, whether P, A, or T,
> undifferentiated.
> Not related to the problem above, but is there a way to have the blank
line
> at the bottom of the portal always visible?
> I'm only showing five related records at a time, with a scroll bar, of
> course, but as the year progresses, the user will have to scroll quite a
> ways down to find the blank line for today's input.
> I've attached a $100 bill to this e-mail... hope it makes it.
> > Portals are designed to facilitate new record creation in the related
> file.
> > If the main file is called Students, it should have, in addition to the
> > usual contact information (name, address, etc.) an ID field, which is
best
> > set up as an auto-entered serial number, with 'Prohibit modification of
> > value' enabled, and validated as unique. If there is some other
necessary
> > and/or useful number attached to the student, such as a School ID number
> or
> > a Social Security number, that's fine-- just don't use them for this ID,
> > which does not need to be displayed.
> > Create a new file, "Days", with, at least, the fields "Date" (a date
> field),
> > "ID" (number), "PAT" (text), and "Constant", a calculation field,
> returning
> > a number, and defined as "1" (the number one).
> > Make Date be auto entered with the creation date. While that will be the
> > most likely value, the user can modify it as necessary.
> > Leave ID alone, as it will be entered correctly from the portal. Same
with
> > PAT, as its formatting will be created back in Students.
> > Constant may not be used immediately, but it's always good practice to
> have
> > a Constant field for creating a generic or 'global' relationship.
> > You can also create name (first and last) fields, making them lookups
from
> > the Students file via a relationship based on the ID, but it is not
really
> > necessary.
> > Back in Students, create a relationship ("Days_ID") to the Days file,
> using
> > the ID field as the match field on both sides. Enable "Allow creation of
> > related records". This step allows creation of related records through
the
> > portal. When "Allow creation of related records" is enabled, the last
row
> of
> > a portal will be blank, allowing entry, and entry of valid values into a
> > field in that portal row will force the creation of a related record (a
> > record in Days), with the correct value for the match field (i.e., the
> > correct ID).
> > I would also enable, in the Relationship dialogue box, "When deleting a
> > record in this file, also delete related records". That box can be
> dangerous
> > to check, but in this case attendance records would make no sense if
there
> > is no basic record of the student.
> > You might also choose to sort the relationship (that will affect how it
> will
> > display in the portal) by date.
> > Now create the portal, making it as large as necessary, checking "Allow
> > deletion of portal records". Place the related fields Date and PAT in
the
> > row. You can elaborate and also add a time field. You do not need the ID
> > field. Create, in Students, a value list for PAT:
> > Present
> > Absent
> > Tardy
> > and format the field in the portal row with a popup or radio button of
> that
> > value list.
> > That's it. If you select a value from PAT, a new record will be created
in
> > Days, with the student's ID in the ID field, and the creation date in
the
> > Date field.
> > You can place a button next to the portal for removing a selected portal
> > row, in case a user makes a mistake (and you can get a little fancier
and
> > add some password protection to control who can add and remove records).
> > Format the button with "Delete Portal Row"-- it will automatically ask
the
> > user for confirmation.
> > To track overall attendance for a given student, in Students you can
> create
> > calculation fields using the Aggregate functions. With a bit of
> elaboration,
> > these can provide the user with a fair picture of the student's
attendance
> > as compared to their classmates. The reason for creating a single record
> for
> > every day for every student is just that, that it creates a rich
database
> of
> > specific information that can be mined quickly.
> > To avoid duplicating the same date for a given student requires a calc
> field
> > using a self-join relationship in Days, and may not be necessary. I'd
hold
> > off on that one, as a sorted portal will quickly display duplicates.
But,
> > yes, it can be done.
> > --
> > John Weinshel
> > Datagrace
> > Associate Member, Filemaker Solutions Alliance
> > Vashon Island, WA
> > (206) 463-1634
> > > Well, I will need some help.
> > > Specifically, can I cause new records to be created from the main
file's
> > > portal?
> > > Can I see which student has which days' attendance recorded, and those
> > that
> > > are 'behind?'
> > > Will I be using 'Unique' validation to make sure I don't duplicate any
> one
> > > day for any one student?
> > > Sorry to be so dense, but I haven't had my breakthrough yet.
> > > Also, I need to foolproof it as much as humanly possible, since a
group
> of
> > > teachers will be using the database, not me, and I'm not even on site
to
> > fix
> > > it.
> > > > To record attendance for a student for every day, you need a second
> > > related
> > > > file ("Days") with one record for every day for every student. You
> > > obviously
> > > > want to keep this second file small, as it will quickly contain a
> > zillion
> > > > records. It really only needs the Student ID, date, and a "PAT"
field,
> > > > although you can add a name field, time of arrival (for tardies),
etc.
> > > > If you are uncertain how to build a related file, and, most likely,
> > > display
> > > > it as a portal in the main file, let us know and we will walk you
> > through
> > > > it.
> > > > --
> > > > John Weinshel
> > > > Datagrace
> > > > Associate Member, Filemaker Solutions Alliance
> > > > Vashon Island, WA
> > > > (206) 463-1634
> > > > "Ray Martin"
... read more »
|
| Thu, 06 Nov 2003 12:57:28 GMT |
|
|
|
Redwi
#11 / 11
|
Attendance << As for putting the empty row at the top, the best solution (there is no simple way to move it to the top, although there are some clever tricks that approximate that) is to ... >> nicely chosen words there, John. :-)
had you used "techniques" and "accomplish" instead of "tricks" and
"approximate", you could have ignited a really long tail to this thread...
Sincerely,
Roger E. Grodin
REDWING FINANCIAL GROUP
"Where OUR business is the ultimate database for YOUR business"
==========================================================
|
| Fri, 07 Nov 2003 17:18:10 GMT |
|
| |
|
