My college-student information tracking system includes (among lots of other categories of information) publications, posters, and oral presentations.

For each of these three categories, I need to track such information as title, date, where, etc.

The upper limit for the number of publications, posters, or oral presentations for any given student is indeterminate in advance since the number can continue increasing during the student's career. Some students could be quite prolific, depending upon their research project.

I am thinking of keeping each of the above categories of information in its own, related database so that the master is not overwhelmed with fields and records for tracking all of the above.

To keep the data-entry user interface as simple as possible, I would prefer that the data-entry staff could enter all of the above information in the master, with the data transparently being stored in the related databases. This would be one to many relationship, if I've got the terminology correct (one record per student in the master, many records in the related file with each record storing one publication or one poster or one oral presentation).

So, for instance, when a given student with a preexisting record publishes a new article, the data entry person would go to that student's record (which already has demographic and other categories of data entered), and enter the appropriate information about the new publication in the corresponding fields. A year later, continuing this scenario, when some other staff member looks up this student's records, the publication-related information would display.

Is this a scenario for a portal? Or is it appropriate for a relationship only?

Would a portal allow a data-entry staff member to scroll through and see a given student's related field in the portal that lists all of the publications' titles (for instance), or each of the publications' journals, etc.?

Many thanks in advance for pointers (or URLs to relevant information in this forum or elsewhere) on how this could be set up properly in FMP (I'm using the standard edition, not developer).

Cheers!

This does indeed seem like an appropriate use for a portal. Almost any of the books on FM should adequately explain the use of portals.

-bd

Many thanks for taking time to reply. Noticed you're in Fallbrook; I'm in San Diego.

I believe I've just succeeded in making a functional portal for publication title. More testing and time will tell . . .