contains a list of tag descriptions attributable to different users, each record has a __pkTag and also a __pkUser field;
Those sound like they should be _fk fields. pk stands for "primary key" and a primary key uniquely identifies the record in which it is defined. __pkTag would then uniquely identify records in a table of tags and __pkUser would uniquely identify a table of users. I wouldn't expect to see both in the same table.
Are these your tables and relationships?
Where TagDescriptions is the table you describe and it then serves as a join table between users and tags?
Portals should work for this, but we need to understand your tables and relationships before we can identify where it failed for you and suggest alternatives.
I have changed Users to Songs as it fits the intended use case better. This is an adaptation of Phil Caulkins's ScrollBars II which you pointed me at in an earlier post.
The change I made was to add an additional table called TagsCreate. This is connected to a single line portal above the main portal that displays all tags.
The TagsCreat::TagDescription field features auto-complete functionality to identify whether a tag was previously created (I can't seem to get Search As You Type to work so have parked this for now).
If the previous tag doesn't exist the user can opt to save this via a scripted button which also performs Phil's Select_Deselect script - meaning the new tag appears at the top of the second portal that displays all the tags along with a check mark to show it has been assigned to the song in question.
You show no Songs table.
And which occurrence is specified in layout setup? By my example in the Adventures file, that would be CatalogueTags. but if you are using TagsCreate to create new tab records, it should be an occurrence of the same table as TagsList. Judging by the field names, this is not the case.
For those reading along at home that might not have the Adventures in FileMaking #2 file handy, this is a special version of a many to many relationship where the join table is not in the normal location nor in the typical relationship.
SongTagList is set up as a join table linking CatalogueTags and TagsList. Using the Cartesian Join plus a script updated global field in TagsList makes possible a portal that lists all existing tags but with a Hide Object When controlled layout object that functions both as a button and as an apparent "checkbox" to show which records in TagsList have a matching record in SongTagList for the current record in CatalogueTags as well as creating or deleting records in that join table in order to mimic the function of a typical check box.
garyjones, if any of what I just posted doesn't match what you intended, let me know as that, in turn will provide me with important info on what needs to be done to get this up and working.
I am using TagsCreate to create a new tag that's not in TagsList and at the same time assign it to a SongID so that it appears in SongTagLinkList.
I was assuming that this latter table would be used for the layout I had in mind. My next step is to filter that by user but haven't obviously got there yet.
Anyway, I've stripped out the above from my project and is here, Dropbox - TagsExample.fmp12
Sorry but that makes no sense. If you are creating new tags, these should be added as new records in TagsList not some other table. and as Bruce said, you don't have a songs table. That last lack may be explained by looking at your file, but not the first.
Catalogue is the same as Songs - it's my poor naming as I regularly change the UI but didn't intend to tidy and standardise until this section was finished. My bad. Also, CatalogueTags is a duplicate of the Catalogue table in my working file.
This structure is a marriage of Phil Caulkins's ScrollBars II and a Magic Key process that was similar in terms of the required front end UI.
I tried what you suggested but the SongTagLinkList table didn't update. As per previous posts I am learning and have a long way to go and this worked.
Sorry, but can't see how putting tags in the wrong table can possibly work.
TagsCreate is a duplicate of TagsList. SongTagLinkList stores the Tags and their corresponding SongId. I sent you a file so you should be able to see from that if there is anything wrong, but my tests have shown the content of SongTagLinkList to be OK.
Anyway, please could I get some help with my original question re. how to display the content of SongTagLinkList.
Thanks as always
Apologies. I just realised that it was your Scrollbars II I referenced and didn't make the join. Nice file!