Insert Picture in Remote Database

[N Cahill]

I want to share a database using fmnet, and allow the user to insert a reference to a jpeg image stored on the server, using the "insert picture" command. How can I format the image reference to make this work? I've tried the local version

image:path/filename.jpg

and the full version

image:/HD/path/filename.jpg

both work on the local machine, but when I log in remotely they fail. Many thanks!

[IdealData]

The fmnet protocol is restricted to fp7 file that are hosted through FMP or FMS.

If you are trying to make reference to a remote jpeg then the remote file system must be mounted on the local machine, ie you must connect to the rmote volume in OS X first before it will become available - sadly this is doomed to failure in mixed platform environments.

Consider inserting the image without reference and the jpeg can be stored in the FMP file.

[N Cahill]

Thank you - that's what I was afraid of. I don't want to embed the images in the FM database - there are tens of thousands of images, so it would greatly expand the size of the database, and the database changes constantly (although not the image references), so I don't want the database to be so huge that backing it up would be a bother.

I tried writing an embedded applescript that would show the images, and this seems to work both locally and remotely on a Mac (actually the same mac - I haven't experimented with two computers yet):

tell application "FileMaker Pro"

set curpic to "Mopsos:Users:nick:Desktop:" & cell "imagename" of current record

set cell "Image" of current record to file curpic

end tell

But can a Windows client execute an applescript on a remote file, shared from a Mac? I don't have a copy of FMP for windows, only the Mac version, so can't test it easily.

Thanks for your help!

Nick

[IdealData]

Okay. First you do have FMP for Windows because you get both platforms for the same license - obviously you haven't tried to install yet. However with the new activation system you could only have one instance installed at the same time as you need to de-activate and re-activate.

If your concern is about file "bloat" and backing up then try this...

Hold the images in a SEPARATE DATABASE. That way you can back up your core data regularly, and your images separately and less frequently. You can still refer to the separate database by establishing a file reference. If you go this route then initializing your image library will take some time, although the import from folder will help greatly. This approach also removes the dependency on the operating system and would still work if you use FMS to host with.

The remote volume approach is still achievable, but you will need to resolve the path references for dual platform, and I would ditch the AppleScript approach as you will need to do the equivalent on Windows (search for posts by Wim de Corte for that).

I appreciate your novice status but you do strike me as someone who has already considered your problem and I think you will do it. There are many posts in the forums on this subject and each one is individual. Consider also a plugin - maybe Troi file plugin (I'm no expert there).

AppleScript will only execute on a Mac.

[cjaeger]

You can store the images on a web server and make them show with webviever. Just store your images within your personal web sharing folder and turn sharing on.

[N Cahill]

Thank you for your suggestions. I tried storing the images in their own database, and it worked fine -- the database is no bigger than the folder of images (430 meg). It took me a bit of time to figure out the proper relationships - the main table looks up photo references in another table in a separate file, which then has to link to a third table in yet another file - but I got it to work by adding a temporary field in the main table, for what image should be showing. It shares properly on this single machine; will test more tomorrow, and try it on a Windows machine if I can. (does the license I bought cover a Mac version and a Windows version on the same machine, if I'm using Boot Camp, I wonder?) The web server also sounds good - I liked the idea of having the image on the same window as the rest of the data, although it limits you to one picture at a time. Will keep experimenting - but you've suggested a very workable solution. Thank you!

[N Cahill]

I've run into further complications which have me stumped. I had it working by establishing a two-step relationship - the main table (where I want to show a single image in a container field) links to a table of image references (many images for each object in the main table), and a separate table held the images themselves. I made it work initially by adding a dummy field to the main table for the current image; I had a portal in the main table that showed a list of images, and a button in the portal set the dummy field of the main table to the image number of the second table; this was then linked to the huge table of images, and a container field on the layout showed the image belonging to the third table.

This works fine if I have read-write access, but I'd like users to be able to use the system without write access, and then the button can't fill the dummy field and so link the image. I've tried linking in all kinds of different ways, and nothing works. The closest I've come is to have a button which goes to the related record, and opens a new window - which is an OK solution but not as elegant as showing it in a container field on the main layout. Is this possible without allowing write access? Should I repost in the Relationships forum? Thanks!

[Fenton]

Rather than set a dummy field to the image, you could set a global ID field to the unique ID of the related image. A relationship using this AND the Parent ID, from the Parent, will show the related image. (The Parent ID is included so that if you flip to another parent record, it won't still show the image; or you can avoid this by setting a regular field as a foreign key to the image ID).

In either case you could run that script with [x] Run with full access privileges (checkbox at the bottom left of the script's dialog).