Why do you have both an info table and a picture table? Is there always just one info record for every picture? If so, you could simplify your table by putting the info and picture fields in the same table. This might, get your GTRR step to work as expected also. Otherwise you might need a script:
Go To related record //specify options to go to the related info record
Go To related record //specify otpions to go to the related picture record from the info record.
Go to relate record is powerful, but quirky and is poorly documented by filemaker. Uninformed use of this script can lead to nasty consequences. To learn more about it, see this link:
The picture is in the info table too, and they're usually pretty big pictures and they're shrunk down in both the album and the info table. That's how the client wants it. Also the client wants to be able to click on the picture in the info table to see an enlarged version of the picture, and I couldn't really find a way to do that so I just made it a separate table and made it really big there.
"The picture is in the info table too, and they're usually pretty big pictures and they're shrunk down in both the album and the info table."
This doesn't make sense to me. They'll be "pretty big" no matter which table you store it in. If there's always only one picture for a given info record, then merging the two tables will not affect this at all. The dimensions of the field you use to display a picture have no connection whatsoever with what table stores the picture or a reference to a picture (if you choose to store them as separate files.)
You are aware that tables and layouts are two different things in Filemaker?
I was assuming the following table structure:
Album, one record = many pictures. one record = many info records.
Info, one record describes exactly one picture
Pictures, one record has a container field that stores either a picture or a file reference to a picture plus a key field (album) that links it to an Album record.
If this is correct, then the Info and Pictures tables can be merged and this will make them a little easier for you to work with.
Is there a way to make a small version of a picture linked to a full sized version of it? Like a gallery or something? I really don't want that extraneous picture table if I can help it.
In the album table, it's the picture except in the layout the field is pretty small, and the picture is resized to accommodate. So I had to make a separate table so that I can have both a small version and a big version of the same image. That's all.
I don't follow why you would place any picture (container) fields at all in your album table. You can define multiple fields in the same record or relate to multiple picture records. Don't see any advantage to placing a picture field in the album itself. (When I refer to "size" I am referring to the size measured in megabytes or pixel dimensions not the size of the field you'd place on a layout.)
Here are two possible examples of how you might set up your picture table:
ImageID (number or name)
Size (text or possibly a number field)
Ah, okay, I think I see where the confusion is coming from.
Well, this database is going to go online and viewable by a bunch of people. It's suppose to be a gallery, but every CMS we tried was missing features we need (poor or missing searching and organizing function, generalized description fields with no customization, etc). FileMaker seems to be the best choice after that.
The people viewing the website are not computer savvy, and it's probably safe to say they don't know what databases are outside of maybe Microsoft Access. So I'm trying to make it easy to look at and navigate, so in each of the albums, I want thumbnails of all the images that are currently in the album, and each of the thumbnails clickable to lead to the full sized version of each of them. I couldn't figure out how to do this other than make a separate table and make the image big there (in terms of dimensions), and then make each thumbnail a button that goes to the related records. The problem I have though is that it always goes to the first entry among the related records rather than the particular image that I clicked on.
It's suppose to act like a gallery, basically, except I'm making it in FileMaker.
If this was just a normal database in maybe SQL or something, then yeah there's no need to have pictures in the album itself, just have it in the picture table and link the two tables together.
Dimensions as in the field needs to be say 4" x 6"? If so, I repeat, this has no bearing whatsoever on what table you use to store the images. To change the dimensions of the field in which you store an image you can simply resize that field to the size needed on any layout--providing the stored image has sufficient resolution to display the image clearly at that size.
I don't think you should store any images in the album table. This has nothing to do with whether or not the users are computer savvy or not. It's a matter of basic relational database design.
You need to answer some basic questions about your data and those answers will determine the structure of your tables.
- Can a given picture appear in more than one album? If yes, then you shouldn't store any image in an album record. Instead, you'd store them in a related table of images and use a relationship to control which image appears in a given album. Even though you've stored the image in a different table, you can still display that image on a layout based on your album table.
- How many info records do you need to document a given image? If only one info record is needed for any picture record, then you can put the info fields and the picture container field in the same record. There's one exception here, if you store several copies of the same image--each with a different resolution (one might be a low res thumbnail and one might be a high res copy for popping up in large format) but only need one info record, then a separate table for info records is logical as you can then link a single info record to several records that store different copies of the same image.