The quick answer is NO.
A more articulate one is YES, but you have to filter the relationship in a way that the dispayed record will be no more visible ( because it doesn't match the imposed criteria )
Depending on wether you want to delete any ties with the parent record, or just hide it from the portal you are using, there are two ways to do this.
Assuming since you are keeping the record from the corresponding database but removing it from the portal you would just could add a field that acts as a flag to denote if the record should be displayed in the portal or not, and then base the portal on a calculated field, instead of the key field I assume you are currently using, and the calc will simply look at the flag and based on its value display return the value from the key field or be blank, and when it is blank the record will not be in the portal. Doe this make sense?
So start by creating your flag, I will call it HideRecordFlag and just make the field type Number.
Now create another new field called DynamicPrimaryKey and make the type a Calculation and for the calculated value use the following, I am assuming your key field to the primary table is called 'PrimaryKey':
If ( HideRecordFlag = 1 ; "" ; PrimaryKey )
Also un-tick the option for 'Do not evaluate if all referenced field are empty' and change the 'Calculated result is' to whatever your PrimaryKey field is set to.
and now modify your relationship to point to the new calculation, DynamicPrimaryKey, from the Primary Table instead of the PrimaryKey.
Finally when you want the record to no longer display in the portal you run a script that places a value of "1" in the HideRecordFlag field and the record will no longer display, but still be in the corresponding table, and if you created another relationship using the PrimaryKey field again you can see that record.
If you did just want to sever the link to the primary table, you just need to run a script to set the PrimaryKey field to blank, or place change the value so it is no longer related.
I hope this helps
Thank you both for answering.
I am much further along now on my school database and like an onion, layer after layer revealing detailed attention! I marvel at you guys, honestly. My mush brain just cannot think this way and your help really inspires me to push myself and I thank you for this.
Ok...my need for this..
It is a 3 year school......each year, there is an exam to see if they progress to the next year or not.
Each exam brings up a portal of current year students from a separate table/database called STUDENTS.
Sometimes, these exams can become too crowded, so we split them into various groups for evaluations.
So my need then is to basically un-choose a few choice students from this one exam and either "send" them to another duplicated exam (denoting the exam is broken now into groups and such) or simply manually choose the students between the two record's portals to separate into these groups.
So I was hoping to keep it as simple and "pure" as possible...like a relationship?
Thanks again for the help. I will try out your ideas now to see how I can use them to solve this roadblock.
So your current portal lists all the students in the STUDENTS table? How is the relationship setup here?
If you don't already have this then it sounds like the best thing for you is to create a join table between EXAMS and STUDENTS, PARTICIPATION for example, that at a basic level just holds the ID of a STUDENT record and the EXAM record, then you can add, delete or move the PARTICIPATION record without affecting the STUDENT records.
You could then advance the data in this record to hold the result or whatever you capture for that student at that exam.
If you want more details on how to do any of this then let me know
I hope this helps