I have a portal which displays 'notes' from related records in layout 1. If I edit the notes in layout 1, they disappear from the portal. Any ideas? Tearing my hair out, here!!
Using a string directly as Boolean value is ... tricky, to say the least. Try ...
not IsEmpty ( Clients::Trainer notes )
... instead, assuming that is what you want to express.
We need to know a bit more about your tables and relationships. Or post a stripped-down sample file for inspection.
There are a couple of ways that a related record can disappear:
- the related record gets deleted
- it's foreign key gets changed or the parent's key changes, thus invalidating the relationship between the two records
- the portal filter calc evaluates in a manner that it decides to hide the record
Like Erolst stated, we'll need to know how the relationship is built, what the portal setup is before we can help you think though this.
okay, so I have a layout 'clients' and layout 'courses'. When a client books a course the field 'confirmed course' is entered with the course number. The relationship are linked by 'confirmed course' in the clients layout and 'course number' in the courses layout. I have a linked table to 'courses' called 'register' where a portal displays 'Name' fields from 'clients' if the 'confirmed course' field is marked with calculation clients::confirmed course. That works fine. I have a second portal on 'register' table which I want to display a list of clients booked, when only there is something entered in the notes field on the clients layout. I am using calculation clients::notes on the portal and no separate relationship. Initially it lists the information I need, but if I edit the notes field on the clients layout, it disappears on the register portal. I have no doubt it is something very simple, but I have mind block!!
To make this a bit easier to digest: I would expect that you have
Clients --< Register >-- Courses
where Register is a join table in which each record stores the fact that a specific client is enrolled in a specific course. Now you could display related records from the join table in
• a portal on a Clients layout to display the current client's registered courses, or, vice versa,
• a portal on a Courses layout to display a list of clients enrolled in the current course.
If you want to see a sub-list of clients limited to those who have a note, you could add a second portal on the Courses layout and filter that.
But from your description it seems you have
Clients >-- Courses --< Register?
That would mean that a client can only ever be enrolled into one course at a time (and you would lose the history for repeat clients if you overwrite the course field in an existing record).
But maybe I'm misinterpreting your description?!
Thank you for your help - I only dabble at this and am no expert, so please excuse my ignorance.
Maybe I'm not explaining it very well. Clients will only ever book one course, there is no option to book another, and doesn't need to be. 'Register' is not layout, but a summery list from 'courses' of course participants which is sent to the trainer. The notes field in 'clients' lists any special needs that the trainer will need to be aware of. So, Register has two portals. One with a list of names to be used as a register for clients to sign against and the second portal to list notes, but only against clients names who have a special need (where the notes field has been entered). Does that make more sense? Maybe there is an easier way or doing it without the need of a portal?
You might post a screenshot of the relevant part of your relationship graph.
While there are a few changes that I would make in that relationship, I don't see anything that would explain what you are dealing with. It does confirm that there's no join table involved--which I also assumed that you had.
Might be useful to show both portal set up and a screen shot of the calculation dialog for the portal filter. So far, it looks like your portal filter is the likely culprit here.
Yay!!! works a treat - thank you so much!!
You might also check and make sure that the field is defined to be type text. If it's number, it will appear to work OK, but you'll get a few odd behaviors that won't happen if its defined to have the right type.
Retrieving data ...