>Herein lies part of your problem. IB/Fb databases are not Paradox, but
>SQL. You neither need nor should implement hierarchical primary keys in an
>attempt to enforce foreign key relationships - the DB engine *knows* what
>to do about foreign keys.

Yes, I do realize this. This database structure WAS originally created for
Paradox. When I switched over to Interbase, I kept the same structure,
which has always worked fine until just recently (probably when I switched
from BDE to IBO, but I can't be certain). I will probably re-do all this
at some point.

>If an enrolment can refer to more than one section
>and/or more than one class, then you have a many:many
>relationship. Although M:M relationships can be implemented in SQL using a
>hierarchical structure, for performance and other reasons, you would
>typically use enrollmentid as a surrogate key for each combination of
>sectionid/classid, and apply foreign keys to each of sectionid and classid.

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?

>Yes, quite a few, but I don't think you want to hear them. The only thing
>here that is pertinent to IBO is what you have applied as MasterFields and
>KeyLinks for each dependent table. With your current structures, the
>MasterFields and the Keylinks should be the same. If you are sure they are
>correct, then you need to look at that redundant relationship which
>customer has with sections and enrollments.

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

-Joe