"I need to attach 1-4 pictures to each file"
I guess you mean 21-4 pictures to each RECORD".
I did a similar database for my favourite painters.
You create the database "Artwork", and then you create fields. The key field would be for example "Artist" and then you have 4 containers fields "Picture1", "Picture2", "Picture3" and "Picture4".
You can choose those 4 container fields as 1) stored or as 2) stored externally.
The stored option will store each image inside the solution, the stored externally option will store the pictures in a separate folder inside the same folder of your solution.
You do not need to organise pictures yourself, you just need to drag and drop each picture inside container fields for each related Artist.
I would use a separate record for each picture and import them into a related table. Can you use the file name of each image file to determine which picture goes with a given record in your table of 2000 records?
Yes, it's a record.
I sometimes have many photographs of the same artwork, and half of those 1000 works are by the same artist.
I tried to make a portal in each record. Would that have the same effect as the container?
I have a seperate record for each artwork, whereas I have 1-4 pictures of each one. They all have a related filename (1a.jpg, 1b.jpg, 2a.jpg ...)
So I guess then that I should import all the photographs into a related table, linking them to each record? Would this function with the "1a.jpg, ...b,c," system. .?
You create the database "Artwork", and then you create fields. The key field would be for example "Artist" and then you have 4 containers fields "Picture1", "Picture2", "Picture3" and "Picture4". You can choose those 4 container fields as 1) stored or as 2) stored externally.
No, don't suggest this even in jest!
The best (and in 97% of all scenarios, only) practice in a relational database is to have a related Pictures table where you can store any number of images in a single container field, but using a (virtually) unlimited number of records, and where you can give them their own attributes.
In short, in an Artist database, images (or more generically, artworks) will and must be regarded as an entity in their own right, and that merits them their own table.
A portal is not made in a record. It's made in a layout. For it to be the "same" you'd place a container field in the portal.
Thanks for all the answers ! I'm new in Filemaker, so it's good to know of a quick responsive forum!
Using Import Records with the Folder option, you can import the images into container fields and import the file name into a text field at the same time. You can then use the text in the file name field to correctly link these image records to the appropriate artwork record. This "by name" match is something that I would use just as a temporary measure before using a looping script to transition to an ID based pair of matching values where the ID is either a serial number or a UUID text string entered via the Get ( UUID ) function.
The first step is to get the artwork name out of the filename. Your ability to do this will depend on your skill with calculations in FileMaker and how consistently you named the image files. Your examples show the artwork name that is always followed by a single lower case letter. If this is the case 100% of the time, a very simple calculation can take the file name and remove the last 5 letters (the file extension .jpg plus that lower case letter a, b, c...).
You can then set up a relationship matching the artworkname field in the artworks table to this calculation field that calculates the artwork name from the image's file name. I wouldn't leave that as my standard link between the two tables as there can be problems when using names as your value for matching records in a relationship.
So I'd then use a script that uses this relationship to look up a unique ID from the related artworks table and copy it into a corresponding match field in the images table and use that relationship once the image import task has been completed. (If you will be repeating this process periodically, keep both relationships by using different occurrences of the same table in your relationship graph.)