And what do you get without the filter? That will tell us if the issue is or is not due to the filter expression used.
You should also post the filter expression.
I_PalGroup should be defined as either a number field with an auto-entered serial number or a text field with this auto-enter calculation: Get (UUID ). The crows feet I see in your image suggest that this might not be the case (unless you are using the UUID option.)
Thank you for the reply.
no, I am not using UUID but anyway, this is the screen shot for the filter equation. I_PalGroup is like a class number. I am actually suspecting the way I set up the whole database tables is the reason why the portal is not working at all but I can't figure out how to work it out.
It would have been better to answer this question that I asked in my last post:
What do you get if you remove the filter?
That would reveal whether the filter is why you only see one record in the portal.
In this case, it does not look like the filter would limit the portal to one record. It also appears that the filter is unnecessary. It simply repeats the logic of your match fields and for that reason, should be removed.
Either there is only one record in Student Details that has a correctly matching value in SD_PAI_Group for the value of I_PAI_Group of the current Instructor record on your instructor layout or perhaps the field in your portal aren't correctly set up to be "owned" by the portal. For this last possibility, enter layout mode and try draging just the portal to a new spot on your layout. (Ctrl - Z will reverse this change). If the fields move with the layout, then the fields are properly "owned" by the portal. If they do not move, you have found out why you are only getting a single record appearing in your portal. To correct this, drag the fields completely out of the portal and release the mouse button. Then drag them back and do not release the mouse button until the borders of the fields are completely inside the borders of the portal's top portal row. You may find it easier to increase the size of the portal row before dragging them back. Test by dragging your portal to be sure that they now move with the portal. Once they do, you can use the arrow keys and alignment tools to fine tune the position of your fields inside the portal row and you can resize the portal row down to a smaller/tighter "fit" around the fields if you had to expand the size of the portal row earlier.
I_PalGroup is like a class number.
Then this really isn't the best field to use for several reasons. In most schools, a given instructor teaches more than one subject in more than one session. You need to be able to link instructors by an Instructor ID field and students by a student ID field. These ID fields would not be values entered into the field manually or imported from another source. They would be internally generated ID's via auto-enter settings in field options.
Exactly how you set up your relationships will depend on how your school is organized. If this is organized like most American Highschools, colleges and universities, you'd need relationships that looked similar to this:
Students::__pkStudentID = ClassSessions::_fkStudentID
Subjects::__pkSubjectID = ClassSessions::_fkSubjectID
Instructors::__pkInstructorID = ClassSesssions::_fkInstructorID
For an explanation of the notation that I am using, see the first post of: Common Forum Relationship and Field Notations Explained