I suggest you consider a consolidated Notes table as a child table to A, B and C.
This not only allows you to define fields to cleanly separate data (the actual note) from metadata (user, creation timestamp), and give each note its own record – instead than cramming them all into one field – but also lets you use this table for all future tables (almost) without adjustments.
Caveat: Your tables should have primary keys that are unique across the entire database (e.g. UUIDs), not just within their own table (like simple auto-incrementing serial numbers).
Like exist stated, you should have a unique foreign key which is sent from A to the other tables. Create a one to one direct relationship from A to each table using that key.
Erolst I was also going to recommend a separate table also but then I thought maybe your favorite List function might work if all that is needed is to view the notes. You could use a calc field that combines the A note, with a list of B notes and a list of C notes. Then display the calc field on the layout.
Like exist stated
You may want to keep your auto-correct on a tighter leash …
And btw, what I suggested isn't really what you suggested – which is piping the grandparents' primary key all down the line to whatever ([great-]grand-)child tables there may be; this is viable to a point, but not really scalable.
Thanks for all the input, let me see if I can implement this. I'll be back..
Thanks again for the quick responses..
Just wanted to let you know this worked beautifully.
The Light Bulb went off when you suggested a separate Table for Notes
I linked it up with the other 3 tables as Child>Parent with a global Field that has the same value throughout all tables.
Then I put 3 portals on my layout, so I can see where the notes are originating from and I filtered the Portal to show only fields with data. Thanks for the help!