Having looked at the sample provided, it's clear that the problem is more complex than displaying related attachments. It's likely that the sample provided is actually not the same as the real tables in the working database either. "Tbl_A" and "Tbl_B" appear to be pseudo tables created only for this uploaded sample. However, if they are based on the same design approach as your actual tables, they are fundamentally incorrectly set up.
The tables are identical in structure, only differing in the names included. There should be ONE table, not two. And whatever the difference is between the data in the two tables (perhaps they represent different police categories, as suggested in the images in tblImagesRibbons. Perhaps "A" is for one of the forces, and "B" for another. Perhaps there is still some other, undisclosed categorization.
Ultimately, improper table designs like this lead to all manner of complications downstream as you try to manage the data.
You need two tables, not four.
TblEmployee-- which I think is what appears to be the entity involved because it has Nome and Cognome fields. In addition to those two fields, you need a field to indicate which of the two other attributes applies, "A" or "B", whatever that designates.
The attachment table is the same as it is now, but combined because it only needs to support the one employee table.
That also allows you to replace the qry_union, which is further indication that "A" and "B" contain the same data, and should be combined with an additional field to indicate that status.
I've done a lot of the prep work to implement this, more appropriate design, along with resolving the problem of filtering attachments by person.
I did some guesswork about the actual content of the database, but you'll need to sort out the appropriate names.
NOTE: I corrected an oversight in the sample I uploaded. This version is more appropriate.
Also, I didn't delete the now obsolete objects and code. I only focused on the table/query/form changes required to more properly model the data.
