portals, relationships, globals

[poetnabotl]

There's clearly something I don't understand about relationships, portals, and globals. I'd post my file but I'm ashamed at its half-done-ness and my amateurity. So I've posted a screenshot instead.

 

Man, I've retyped this five times trying to keep it short. Here's the long story:

 

Attendance Marking:: portal1 is a (perhaps confusingly named) calc field which = Attendance Marking2::classID, related by g.date.

A portal on the Attendance Marking layout then displays related records from att_StudentsClasses. The fields are att_StudentsClasses::studentFullName and att_Attendance:: present.

A global field on att_StudentsClasses = Attendance Marking::g.date.

If att_Attendance is related to att_StudentsClasses by studentID AND classID AND g.date, then why are records showing up in the Attendance Marking portal when Attendance Marking::g.date holds a different value from Attendance::date?

 

Hm. Should I just suck it up and post my file?

 

Thanks if anyone has the fortitude to work through the mess above.

[Ender]

You should probably clarify:

 

What do the TOs actually represent? It's easeir to understand if your TOs are named with their table, and if necessary, relative relation. For example, the primary Attendance TO would be called "Attendance", and the primary Enrollment TO would be called "Enrollment". If another Attendance TO were related in a different way (say for interface purposes), you might call it "Attendance by Selected Class_Date"

 

It is also useful if the TO colors provide meaningful information, like using a different color for each base table's TOs. With your current naming and color scheme, it's difficult to tell what the TOs are for.

 

Also, what is the base TO for the interface this is used in?

[poetnabotl]

Sorry 'bout that. The relationship graph is color-coded and named in a way that helps me and no one else. I've tried to rearrange it in a way that might make sense to others and reposted it.

 

The base TO is "att_Classes for Attendance Marking" (previously called Attendance Marking). That's where the user will choose the global date, which will display the appropriate classIDs in "att_Classes for Attendance Marking::c.portal1", c.portal2, etc. fields. Which will in turn relate the table to att_StudentsClasses. Which then populates the portal on "att_Classes for Attendance Marking" with att_StudentsClasses::studentName and Attendance:: present.

In theory.

 

Also, att_StudentsClasses::g.date needs to hold the same value as "att_Classes for Attendance Marking::g.date", in order to relate the whole thing properly to Attendance::date. Which is my hitch. It seems to be related no matter what value att_StudentsClasses::g.date holds.

(Final note: You're only seeing part of the relationship graph. The TOs where kids are assigned to classes is in a different part of the graph.)

Does that clear anything up? Should I just post the file?

 

I appreciate your response.

Jason.

[poetnabotl]

It's almost working. I've set the g.date field on the interface table to display values from g.date in StudentsClasses. And now I can mark attendance and it seems to work great. I'm having an issue now where there was a c.field = DayName(att_Classes for Attendance Marking::g.date), which isn't working properly anymore. And I think it's because "att_Classes for Attendance Marking::g.date" isn't the field I'm using anymore. I think I'm using the StudentsClasses::g.date field on the "Attendance Marking" table. So now I just need to use the same table I was using before but just have it use values from StudentClasses::g.date.

Still working, my friends. Still working.

[Ender]

Glad you're working it out.

 

I'm still having trouble understanding what you're graph is doing. But if you need further help, go ahead and post a clone of the file so we can get a better handle on it. It seems like the graph should be a little simpler than what you have.

[poetnabotl]

The layout from which the user marks attendance has four portals on it. We have four rooms, which with a class going on at the same time. So when you choose the appropriate date and the appropriate set (eg, set 1), the first four classes of the day show up, one in each portal. Figure, why change layouts for each class if I can show four at once? When "set 2" is chosen, the next four classes for that day show up, one in each portal.

Right now I'm only concentrating on portal1 because I figure if I can get that working I can get the other three working.

Is that the complexity you're talking about or do I need to look at something else?

[Ender]

That's one thing. I'd put the attendance interface on the Class layout, and switch classes (either with a list or portal) to enter attendance for a different class. In my mind, the teachers for those classes only need to see their own class anyway, so why show all at once. But I assume you have a good reason for all that.

 

The other thing I'm puzzled about is why you're relating through the Students TO. Why not relate directly to Attendance?

[poetnabotl]

As kids come in to the school, they pass by a front desk and sign in on one of four sign in sheets, all sitting in front of me. (That's the extent to which we take attendance.) True, it's absolutely not necessary to have all four visible at once. But I figure if I can just click as each kid walks in, without having to switch layouts or views or records, it'd just be a fraction easier.

 

Um... that's a good question. Why aren't I relating directly to attendance? Um... Oh! The table it's relating through isn't a Students table. It's actually the join table of Students and Classes. So there's one record for each student for each class. I figure, if that information is all in that table anyway, why not use that table to generate the Attendance records, simply adding a date field in the process?

 

But you've gotten me thinking... I mean, the students' IDs have to be in there somewhere. There has to be an occurrence of either the Students table or the StudentsClasses table, otherwise I'll have no kids' names to display in my portal. (I hope that's right.) But you've gotten me wondering whether that table is in the right place where it is. Currently I have to have g.date in there twice, once for the user to select (and also to use as a filter to get only current classes), and once so the Attendance table has a date field to relate to. But, in order for them to be the same value, one of them has got to be an unstored calc. Which messes up my relationship on one side of the graph or another. I wonder if relating Attendance directly to the Classes_Attendance Marking TO (which it sounds like you think I should do), and putting the StudentsClasses table elsewhere, I might solve my g.date calc problem.

[Ender]

Ya, relate directly to Attendance, then have Attendance related to Student (or Enrollment) for showing the Student's names in the portal of Attendance. This way, the Date field is related directly, and you won't have any nasty refresh issues to worry about.

[poetnabotl]

Alright, I'm stuck. I don't really know how to relate the tables to each other to get them to do what I want them to do.

 

It works perfectly as is but, as you predicted, has nasty refresh issues. I have to reselect "g.set" (the only non-calculated criteria used in the relationship) to get the relationship to work. And that could get really confusing for someone who thinks they've changed the criteria and goes ahead marking attendance, not knowing that they're making wacky records.

 

But I'm not sure, if I relate Attendance directly to my "Classes_Attendance Marking" table, how to sneak the kids' names onto the record. Near as I can tell, in order for...

 

I'm not even sure what the problem is. Sorry, brain fried. I'm attaching the file. There are probably extraneous fields lying around, the thing is really ugly, and there may still be stuff that doesn't work properly. I hope you'll forgive me. And don't tell my mom.

[Ender]

I see why you had it that way; as a way to create Attendance records through the portal.

 

My suggestion is to populate all the Attendance records for a day via script, then the structure is a little easier. And since you're taking attendance as they walk in the door, why not make a combined portal, sorted alphabetically? Rather than look in four portals for a student, look in one.

 

See attached.

[poetnabotl]

Absolutely brilliant. I'm still taking time to dissect it but I really appreciate your help on this. It would never have occurred to me to use "import records" in a script like that. Because, ya know, I ain't too bright.

When I first saw your post, I missed that you'd attached a file (it was late), so I spent some time attempting a script of my own which, I gotta tell ya, wasn't nearly as elegant as the one you used.

Anyway, thanks again.

Jason.