Picture container

[cebulskis1]

I am puttin together a database for the university's public affairs office that I work in. We are trying to catalog all of the images that we have from various shoots. Currently I am up to 2500 images which cause the database to run realy slow.

These images were inserted into the container field to allow the other users on the network to see the actual picture and not just the file path refrence that you get when you use the import function.

Is there a way that I can get the picture to show up in the container without having to insert the entire picture (someone told me that i should link it with relational keys but that is total greek to me).

[Genx]

.... Use a network path maybe?

[cebulskis1]

can you be a little more specific please?

[Fenton]

I believe what Genx meant was to put the actual picture files on another machine, a networked server, which would then be mounted on each client machine. Then Import Folder, with the option [x] Store only a reference.

The reason for a separate machine is that it must have OS file sharing on, whereas the FileMaker Server machine should not. That's my (and FileMaker Inc.'s) preference; it's a little controversial (some people think Russian roulette has acceptable risk also -).

We don't know what your structure is, such as whether the pictures are currently in records with other data. It is possible to use the "Matching records" option when importing, which would work if you have either unique file names or a unique file path in the record. Since the pictures are currently embedded the latter is unlikely.

Another possibility, if the structure of the folders the pictures are in is well-known, is to create file paths to the pictures within a FileMaker calculation field, result container. The calculation would produce a result (if it was text) that looked like:

imagemac:/server volume name/folder path/file.ext

The calculation method has the (great) advantage that you don't have to import. But it only works if the folder structure is very clear. It is possible to combine the Import Folder method with the calculation method, to get the path. That advantage of that method is that you can change the volume name, or adjust the folder path slightly, without breaking all the links; which otherwise would happen.

You can read more about this in the FileMaker Help. It's there, just hard to find all the pieces. Or do some searches here on the forums.

Edited June 20, 2006 by Guest

[Genx]

The solution to allowing network users to view the file is pretty clearly going to be putting the files in a network location ... i.e. having the file referenced in a way that all employees can have access to it. Think of it as a shortcut.

You don't even have to have the volume mounted, you could just use a direct path like serversomefolderIMG110202.jpg ... or whatever the syntax is for mac.

[Genx]

Fenton, could you elaborate on the russion roulette thing, and is it really that bad in a small environment of no more than 20 users?

[Fenton]

As I said, a controversial subject. Not being a software engineer and network expert myself, I tend to take warnings not to share the FileMaker file's folder, or its volume seriously. I can show you several quotes by both FileMaker itself, some from its employees, and a few from other recognized experts who say that it can eventually lead to file corruption.

FileMaker sharing is NOT OS sharing. That is why it works cross-platform out of the box. The two apparently do not really know what the other is doing, hence the potential for both to access a file at the same time, possibly causing small damages, which can eventually add up to non-operational files.

Most people want to use the same machine simply because it is cheaper and more convenient. If you've ever had to try and restore a damaged file you realize just how specious this reasoning is.

I know of a (very) few experts who say a shared machine can be configured to be safe. That might be true; but I have no way of knowing myself. The preponderance of testimony is on the other side.

Quoting from Jimmy Jones (FMI engineer) on this issue:

Sharing the FM folder that the files reside in can cause a FM crash. My understanding is that the cause is the very complex interaction between the TCP/IP network layer (typically this occurs only in TCP/IP), OS file sharing interaction with the OS security, interaction between FMP file data requests using the TCP/IP stack and the OS security trying to prevent inappropriate file access of a shared volume.

Scenario;

1. The folder in which the FM files reside is shared by the OS.

2. FM is sharing the file(s) using the selected protocol.

3. The OS is charged with preventing inappropriate access of the files on the hard drive (but the FMP program is running locally!).

4. Now the OS detects a request for data using a file access over the network, since the file is in a shared volume the OS thinks it is supposed to read/write to the file it tries to authenticate the access. However, there is no 'real' network access going on and there is no user interface and (remember FMP is running locally) no way for FMP to tell the OS the access is OK. The OS gets confused and crashes FMP. Since FMP has its own sharing stack using the protocol the OS shouldn't get in the way, but if the folder is shared the OS will try to authenticate file access privileges. The problem seems to occur because the OS level security thinks the network request for file 'data' should be authenticated even though it came through the FMP stack and the local copy of FM will do the actual file access. Go figure." So what happens when FileMaker files are located on shared volumes? Network performance degrades and there is risk of file & data corruption.

[Razumovsky]

I had been under the impression that this only applied to the folder the DB was in. IE- If the database folder was not shared but a different folder that just held the pictures was, there would not be a problem. The blurb you quoted does not seem to contradict this notion, but I have never experimented with it.

[Genx]

I thought we were talking about file sharing in general on the same server as the filemaker file is being hosted off.. not putting the filemaker file itself on a network drive.

[Razumovsky]

I thought so too.

[Ricardo]

Just get a PC and run Server 2003!!!

[Genx]

Not worth it in a small environment of 10-15 users, especially when managers are stingy on tech.. And SQL, MySQL and all decent data base servers don't require a completely seperate server to run them (granted they do run optimally that way).

[cebulskis1]

stingy is not the word for it around here.

[Genx]

And the word is then... Tight? Cheap? :)

[Ricardo]

and FM Server does?

[Genx]

Well no, i'm just having a non existant argument with Fenton about a point he never really made but hasn't clarified. :)

[cebulskis1]

I hate to say it but alot of this is just over my head.

All of the files are on an external hard drive on the server machine.

When said files are imported they do not appear in the picture conatainer on any other machine than the server machine.

File sharing is on for both the database and the server machine.

Files still not found.

also note that there will be thousands of records in this database and speed is necessary

How do I fix this? (in simpe tech speak please!)

Edited June 28, 2006 by Guest

[Genx]

Simple tech speak eh?

Use full network references, not local references.

You should be using the reference: image://comp name/some folder/some thing.jpg

i hope i got the syntax right this time, i always seem to stuff it up.

Oh well, basically as above, you have to schedule the full path of your content, including the computer name it resides on, folder etc. etc. Alternatively, you could map network drives on every computer to this folder and then you'd be able to evaluate using simple references e.g. file:USomething.jpg

The trick is that you need to understand that FM evaluates these calcs with respect to client side not whereever the file is being hosted --> hence if you reference c:image.jpg, the client filemaker (whichever comp it happens to be on) will try to evaluate the path c:image.jpg

I really don't suggest you trust my file reference format's and simply look it up in the help (i don't usually deal with mac's so i'm trying to improvise here).

Anyway, jargon is no fun, but hey,

You'll probably still have questions, so post away, to be honest i'm just trying to get Fenton to clarify his point.

~Genx

[cebulskis1]

actually that was really helpful. thank you so much!

[Argento]

Ok I've kinda got the same problem as a few of you. I have a huge database of about 4,000 pictures. I used Graphic Converter to make the images about 15K a piece so it loads quickly etc. Obviously this means I had to really dumb down the quality, resolution etc. I have imported these images without using the file reference option since they are so small.

I am using a quad G4 2.5 ghz Mac, so I'm working on the same machine that will be used as the server.

The problem is I don't know how to make it so when people are looking at the files I have up, I want them to be able to click on the image (or button) that will allow them to download the large image file. The problem is I have no idea how to link the two together.

As it stands right now I have them on two different layouts. One of the databases has the small size (15K) pictures with text defining them, and the other database has the large pictures (3 megs) with no text. I know I have to make a realtionship between them so it'll import the text but how do I link them so the large images (3 megs) can be downloaded, but not displayed?

[Fenton]

So, you have both the down-sized and full-size images embedded in separate FileMaker files? And you're going to link them (which you say you can do)?

If they're both inside FileMaker and linked, then you should be able to use the Export Field Contents step to let people "download" the larger image. This step (like most) evaluates on the client machine. Therefore the path you use must be valid on the client machine.

Pre-version 8; there are 2 problematic factors. The 1st is the hard drive name. It's best that people do not rename their hard drives. The other is the user name, which is different for each person. That makes it difficult to export directly to somewhere like their desktop. On Mac OS X there are a few locations that can be relied on. There is a Users/Shared folder (which has the hard drive name, but not the user). Once it has been exported, you can run a simple AppleScript, in a Perform AppleScript step, to move it to their Desktop. AppleScript can easily get this location. If you need more direction, write again, or search here on fmforums; I've described it more than once, but it's been a while so it may be gone.

The easiest solution however is to upgrade to 8 (8.5). There are new functions, like Get (DesktopPath) which are cross-platform. You can set the name and location dynamically in an Export (search here also; we see this question very often).

With 8.5 there is even another possible solution, which is to turn on web sharing, and put the pictures in the appropriate folder. Then use the WebViewer object to show them. I haven't tried this, but I don't see why it wouldn't work. Also, I don't think Web Sharing is a problem like File Sharing, since it only affects certain folders, and it a separate kind of sharing.

[ Problem with using WebViewer. The picture is full size. You'd have to make your WebViewer as big as the largest possible image dimensions. Then they could scroll. So it has less features than a FileMaker container field, which can Reduce. ]

Edited July 27, 2006 by Guest

[cebulskis1]

ugh I thought I had the problem solved but I totally dont.

I am obviously going to have to create thumbnail images to use in the picture container to get the file size down (our database is going to end up being around 10,000 photos (about 250g right now) by the end of the month) and as they are once you get past 60 images the database moves slower than whale poo in janurary.

I'm not sure how to link the thumbnails to the large images and what you just said went wayyyyyyy over my head (it's like being in another country and not knowing the language!).

[Fenton]

Sorry. I was really answering Argento. I suppose we should have moved that to a different thread. The problem with deciding how to do pictures is that there several alternatives. None of them is perfect. It depends on many factors of your actual situation which would work; and even then there are choices. So it's hard to say "This is the right way."

Some of the factors:

1. How large are the full-size images? And about how many?

2. Do you have access to another "file server" machine (separate from the FileMaker machine)?

3. How are the images going to be used? Are they going to be "downloaded" to users' machines? Are they going to be modified, then "uploaded" again?

4. Is there a consistent organizational scheme to the folders and names of the images, such that the database could construct the path from its fields?

#3 determines to some degree what to do about thumbnails. If they modify images and expect those modifications to show in a thumbnail, that means redoing the thumbs (PITA).

I don't really see why having a lot of images should slow a database to a crawl. If fully embedded (not inserted or imported "As reference only"), the big images should NOT be in the data file, where you'd be searching, etc.. They should in their own simple related file. They should only be viewable in the data file on a Form view layout, as a related field. That way your other data is not held hostage by big images.

If they're inserted "As reference only" then they'd be in the data file, but only stored as a file path; a small amount of data.

The thumbnails (like 128x128) could be embedded in the data file. Or they could be files in a folder, also stored as reference only (which is the way web pages are done).

Look at the FileMaker Help. Look at the Import Folder command. It can create 128 thumbs on-the-fly, embed them, and import the image as reference only, and the file path, and the name, all at the same time, including nested folders if desired. This was added in FileMaker 6.

If the file names are absolutely unique, and you have that name in your FileMaker record, you can use it with Import Matching to line up the pictures with their records.

[cebulskis1]

[color:purple]1) The large files are about 29mb each

2) No there is no way to use a server outside of the filemaker running machine

3) The images need to be able to be exported to the machine of whatever user needs it.

4) The name used in the name field is the same as the actual file name.

I have tried to read the filemaker help but it hasn't been helpful at all. I’ve only had a short while to putz around with the program as it is, and I don't really have a whole ton of time to play and figure out what I’m doing at this point. By the end of august this thing has to be up and operational.

As it is, if I import images (reference only) once you get 200+ files up the program starts moving very slowly. I realize this could be an issue with the server machine all together as it is quite old, but they refuse to give me a newer machine to work with so I have to optimize the performance as much as possible through the set up of the database itself.

I know I must sound like a complete idiot, but I got thrown into this project without ever having used filemaker or any program like it before. I'm teaching myself everything because no one in my office knows anything about it and the tech support here is virtually useless program wise.

Edit: What I really meant to say was I have the thumbnail part, but I can't figure out how to link it to the large file so when you hit export it exports the large file and not the thumbnail

Edited July 28, 2006 by Guest

[Fenton]

OK, then even the big images should be embedded into a FileMaker database.* You would likely do this by use Import Folder, unchecking the [ ] Only as reference option. Yes, the file would be huge. You should definitely keep the original images, in case that file gets corrupted in the future (always a possibility with images). The file would have only those necessary fields in it.

If your file names are absolutely unique, then you can can use them for a relationship to the main data file. You could do a 2nd import of the images to the data file, but ONLY import the Thumbnail. You can specify which things you want to import in the Import Order dialog. It will create a 128x128 thumb on the fly.

If you want a medium size also, then you can do that with any decent image editor, Photoshop, GraphicConverter; or it can be done with AppleScript. That would likely be imported into the Images file. I'd recommend this. Because 28 MB has way more detail that even a large screen can show. For example, I have a bunch of space pictures, jpegs, sized to 1680x1050. They are generally 500K to 1 MB.

You'd want to use the Matching Records option for the "thumbnail" import, with the File Name as the match field. If you don't know what I mean, read about it in the Help. You do not want to get this wrong. Show All Records in the data file before the import, so it can match any record.

Since all images are embedded. You might want to do this work on the fastest machine you have. I don't know if your "old" server is going to work well with these full-size images. I figure 2500 images at 30MB each is an over 70 GB file. FileMaker can handle it, I suppose. But it so far less than optimal, one could say questionable.

* Personally, I think it's wrong to even put the full size images into FileMaker. Because, as I said, you cannot tell the difference between a 1 MB picture and a 30 MB picture on the screen. You could more easily show them a medium size image, then let them download the BIG picture, via URL or something.

Further, if you Import as Reference Only, as you say you're doing now, you are relying on OS File Sharing to show the pictures. Which is against FileMaker recommendations. Add an old machine and lots of large files, and I'd say you're looking at trouble.

You can solve most of your problems by batch-converting those big images to get smaller (file-size) copies. They will look the same on the screen and will better suit your equipment.

[cebulskis1]

I think we have a bit of a miss understanding.

I'm not looking to put the large file into filemaker because as I said in an earlier post is creates some serious lag issues. The thumbnail images eliminate this lag issue, but creates a problem with exporting.

The office I work in is public affairs related and the images need to be the highest quality for publications. When using thumbnails in the container the export function will export only the thumbnail. I need it to export the Large file to whatever desktop it was requested from.

All of the large files are in a universal location sorted by their disk numbers. Within the disk numbers each file has a name unique to itself.

[David Cartwright]

What you need is to scrap Filemaker and get Microsoft Access.

I have easily managed to link photo's in MSAccess with a bit of VB code.

However my Head of Service is insisting that we have a certain database in Filemaker. This Filemaker databse needs to view photos on forms and reports but I can't work out in Filemaker where to put my VB code. :P

[comment]

I'm not looking to put the large file into filemaker because as I said in an earlier post is creates some serious lag issues.

If the large file is not in Filemaker somehow - either embedded, or stored as a reference only - then Filemaker cannot export it. I believe the "serious lag issues" are easily solved by not putting the large container field on the layout. Select the image you want by browsing the thumbnails, then use Export Field Contents [ ] to export the 'real' image.

[comment]

If I understand you correctly, you are saying this:

I don't know how to use Filemaker;

I do know how to use Access;

Therefore, you should be using Access.

[cebulskis1]

Ugh. Look I get that the large file is what lags it. I also get that I have to some how link the thumbnail to the large file through a relationship. What I don't get is how to do that.

Tech speak is wasted on me which makes the filemaker help a difficult in this area. All I need is simple English directions, not the same patronizing explanation over and over again.

Seriously I know people like me can get very aggravating to people like you who know what they're doing, but I'm learning.

[David Cartwright]

I completely agree. I should be using Access but am being forced to use Filemaker.

But after looking at numerous books and forums, it seems that filemaker can not do what Access can do, Unless I am just not grasping the way that filemaker works.

[LaRetta]

it seems that filemaker can not do what Access can do, Unless I am just not grasping the way that filemaker works.

Second sentence is correct.

(ex-Access developer)

[comment]

I am not sure what you mean by "patronizing explanation over and over again". That was my first post in this thread, and I haven't noticed anyone else being patronising either. Some "tech speak" is required to explain what you need to do clearly enough. You are expected to make some effort on your part as well. I thought I had explained what I meant quite clearly. Now I am hesitating if I should attempt another explanation, and risk being patronising. It seems like a lose-lose situation.

[cebulskis1]

I am making an effort, but i'm having to learn how to use this program from scratch. i've never used filemaker or any other type of program like it before.

and what I meant by the patronizing is that every explination I get is the same expination only worded slighty different. i'm not a total idiot, I get what people are saying. I just don't get how to do what people are telling me to do correctly and it seems to be more an issue of language than anything else. I get lost halfway through the process.

[comment]

OK. Here is a suggestion. Make yourself a new file just for learning this. Define a table Images with the following fields:

ImageID (number, auto-enter serial number)

Image (container)

File Name (text)

File Path (text)

Image Thumbnail (container)

Prepare a test folder with some images. In your file, select File > Import Records > Folder..., and select 'Picture and movie files' + 'Import only a reference..'. Click 'Specify' next to 'Folder location' and navigate to the test folder.

Align the source fields with the target fields by matching names. Click 'Import', and turn 'Perform auto-enter options..' on.

Go to Layout mode and delete the Image field from the layout. Add a button and define it to:

Export Field Contents (it's the last step under Fields)

Click 'Specify target field' and select the Image field. Leave the output file unspecified for now.

Go to browse mode. Navigate to some record and click the button. Choose the desktop as the destination.

When you have this working, we can talk about scripting the output to be always the desktop.