Ok. Tough question time.

This is one for the gurus, because I've got at least two massively different ways to do this and I wanted opinions about how to do this in the Seperation Model because the display will change per user, but the data will be edited and remain the same independent of user. Make sense?

Problem:

Display (VISUALLY) in a 'calendar' the attendance of individual students. Possible 365 days per year, Different Hours attended possible, 1000+ students.

Use the Seperation Model to provide for differing display options.

Probable (or existing) solution components:

Customer DB

Attended DB (key:Customer - 1 per date)

?? DatesAvailable DB

Possible Display options:

Calculated container field (repeating)

or

Related conatiner field (non-repeating)

I see a major issue using related fields to display the results, PER STUDENT. It would take 365 relationships or 365 field definitions to match the 365 days of the year. Ow.

Or use a repeating field (365) to hold the calculated results for each student, and use a single Calc repeating field in the display file to hold the related record repeating display field.

Questions, Comments, Examples :P

Edited November 24, 200619 yr by Guest

Can we take a step back and ask why? I just don't think it would be useful to see all those days on one layout or report.

Ahh.

Recording and viewing at the source (per customer)

AND

I see your point(s) about the display of lots of info, but what would life be without a few challenges and ridiculous requests from customers?

Edited November 24, 200619 yr by Guest

PS -

We want a visually exciting interface for the data, which changes by viewer.

Edited November 24, 200619 yr by Guest

I see a major issue using related fields to display the results, PER STUDENT. It would take 365 relationships or 365 field definitions to match the 365 days of the year. Ow.

What makes you say that?

It can all be done with one relationship. Portals can have multiple rows, right? And you can break portals up, row 1-7, 8-14, etc. There's no reason this can't be done with one relationship. You probably do need an all-days table though.

Agreed, and that's the assumption that I'm working on now as a temp fix.

But the elegance of describing and using a global calculated repeating field holding the related instances is just too tempting to pass up and I'm continuing this avenue as well. Will publish if and when completed.

:)