At 01:24 AM 18-12-02 -0800, you wrote:

>No, an enrollment can only refer to one section, and a section can only
>refer to one class.
>
> >You don't explain the relationships that customer has with enrolment and
> >section, but in some fashion it is this redundancy that is causing the
> >problem you describe below. In SQL terminology, you have either a
> >transitive or a circular relationship involving customer - neither of which
> >is desirable in relational logic.
>
>A customer can have many enrollments. A customer can even be enrolled in
>the same section more than once. A single enrollment record links to
>exactly one section and exactly one customer.
>
>A brief rundown:
>
>Classes:Sections = One:Many
>Sections:Enrollments = One:Many
>Customers:Enrollements = One:Many
>
>
>I don't understand what you mean by this "redundancy". I don't see
>anything redundant or circular in this logic. Could you explain it a
>little more?

No, not unless I understand how you have implemented the two relationships
(Customer to sections and Customer to enrolments).

>The TIBOTable that controls the enrollment list grid has MasterFields set
>to CLASSID;SECTIONID. KeyLinks is set to AutoDefine. It this correct?

It should be; but ry setting the KeyLinks explicitly and setting
KeyLinksAutoDefine to false. Of course, I was wrong saying the KeyLinks
and the Masterfields would be the same. The keylinks should be the PK
columns in correct order. Masterfields should be CLASSID;SECTIONID for the
Sections table and CLASSID;SECTIONID;ENROLLMENTID for the Enrollments
table. Or, if you want to see whether autodefine is viable for your setup,
do a check on the KeyLinks property of the two tables at runtime
(Showmessage(KeyLinks.text))

Helen