I'm not sure of your process for creating a new student, but you could, include in that script, the following:
1. Get the ID of the student record into a variable
2. Navigate to the Courses layout
3. New record
4. Set the ID_Student field with the value in the variable. Set any other data.
5. Navigate back to this layout.
I'm curious why you need to do this. Is it to have something in the portal? Or are you actually enrolling a student at that moment? In a homeroom, kind of thing?
EDIT: Just re read. Since you're in the context of the parent layout, is that layout based on the Student TO or the parent TO?
You might want to try setting an On Record Commit trigger on the data entry layout that returns false when the current record does not have at least one associated child record. When you navigate to a new record with a script step or FM native UI button click it causes an implicit commit. The ORC trigger fires BEFORE the commit action and if the calculation returns false it prevents the action that initiated the trigger.. hence prevents moving to a new record. Take this approach with care because their are edge case considerations... i.e what happens when a user force quits FM before this trigger fires? How could user get stuck in this process? If you need a seriously detailed data entry process then you might want to do a search for filemaker and transactions. This is from a very tired brain so standard idiocy disclaimer applies.
if I get this right, you wanna force a student to enroll at least 1 course. Though what shell be the consequence if not?
Just to prove if he did enroll is easy. Than, I think a specific follow up shell be triggered.
Let's say you have a table 'Students' and a table courses_students_enrolled.
From the parent table 'Students', set a vars for Students::ID, for table 'Courses', set new-record an paste the vars into _fk_Student_ID.
Students::ID = Courses::_fk_students_ID
For parents table 'Students' is:
if isEmpty (Courses::_fk_students_ID) => prompt a error-message / stop from proceed, unless condition isn't changed
Thank you all for the replies.
Just to ADD:
1)When the student joins the school he/she is enrolled into at least one course .
2)There are no students who aren't enrolled in any course.
The problem is that the data entry staff were not entering the courses enrolled into the portal .
I want to make sure they don't exit the student layout, or leave the student record without entering at least one course into the portal which is supposed to contain the related courses .
sorry I wasn't making myself clear.
There is one Students TO and another , Courses TO .
Both are connected with a one-to-many ( Parent is to Child relationship )
I just want to enforce that each parent record ( a single students profile ) must have at least one course entered in a child record in the portal .
they don't exit the student layout
rings a bell, like layout script triggers -> onLayoutExit
but "data entry staff does not enter the data" is another problem we know, which I usually solve brutally, with a modal window you can't get away from until you entered correct data in all the globals I've put on it.
Our core business is sw for doctors and clinics; when creating a new patient the data entry staff MUST enter sex, age and - as related record - at least an insurance. (similar to your course). No way to circumvent that.
Think interaction, you have the power to define it; don't stick to mere layouts and data and field validation, think about steps that have to be completed before advancing to the next and don't be shy about establishing a clear path for the lazy / clueless / not experienced. Power and freedom belong to those that proved worth it; the rest must breadcrumb the path.
I don’t think in layouts, I think in phases. You have a new record phase, you better leave that phase with your backpack full of what you need to continue the journey. Layouts, popovers, validations, fields are only vehicles, are only means, pockets in your backpack that allow you to store the data you need for the next phase of your trip. Your trip must reach different places and every place will let you enter it if you have onboard what it takes. If the places comunicate with each other, as it should be in a well-organized information flow, they might as well anticipate problems by not letting you leave the place N without what place N+1 will ask you to show off already in your backpack. In other words, you gotta see your system’s layers from above and coordinate the data; it’s all about data here, who cares about layouts….
Re: "There is one Students TO and another , Courses TO .
Both are connected with a one-to-many ( Parent is to Child relationship )"
I realise I am not addressing your actual question, but I suggest that you might want to rethink this. If you have a direct relationship between the Students TO and the Courses TO that is not one-to-many but many-to-many (each student can be enrolled in many courses, each course can have many students doing them). It seems to me you need a joining table—call it enrolments or something, so that each enrolment record links one student with one course.