Try a calculation field that uses Length ( yourContainerField ) and see if that works for you.
You can also reduce file size by using store by reference when inserting images. (A script can take the image after it is pasted, exprot it to a file server's shared directory, then re-insert it into the container with store by reference selected.)
You can also put your images into a related table with one record for each image and no longer be limited to a total of 7 images per record.
What would that script look like?
Set Variable [$FilePath ; "File: Put file path and file name here as literal text or a calculation that returns text"]
Export Field Contents [YourTable::YourContainerField ; "$FilePath"]
Insert File [Reference ; YourTable::YourContainerField ; "$FilePath"]
Note, the filepath you use will depend on the Operating system and the drive/folders on your server that you set up for this purpose. Make sure each new image file is exported to a unique file name or Export Field Contents will overwrite the previous file with the same name and no warning message will be returned to tell you that this happened.
I was wondering if you ever got this script to work or the setup of the related table. I am trying to set this up now and not able to get it to work correctly. I have the same problem you did, where I have 6 image containers with images in them already in a database with almost 13K records and my database is running very slow. Trying to figure out a way to house my images in one place but show in my current image container with out slowing down the database. Any suggestions would be very helpful.
"I am trying to set this up now and not able to get it to work correctly."
If you describe how your efforts failed, your description may suggest either an alternate approach or a more detailed description of the method in order to help you implement it correctly.
I already have a simple script setup to insert a image. However, now after 13k records later we are starting to see that the database is running very slowly. And we were unable to save as a reference in fear that image maybe lost if someone moves them from their computer. Now that we have run into this issue, I am trying to set up a way to house these image files into another database file completely then reference the images from that file so our current database so it is no longer slow. Or move to our server in a directory and reference the files from there. But I am try to find a way to do this also for the existing files that are already in the database. So when I saw the suggestion above of your script I just added it to my current insert picture script and did my file path to point toward a new database file I created image containers. But no luck.
So my issue is a 2 fold. Take the images that are already saved into a container, tell fmp to save them to a new location on our server or in a new database file to hold the images, but keep the images in current container as a reference file. And then any future insert picture scripts run will save the image to the same location on the server or in the new database file and store in the image container as a reference file. Not sure if I am making any sense I have been at this for a while and feeling a bit cross eye'd.
Apologies for not making the connection to your other thread in FM Server!
As I posted there, I can't quite concieve of how moving the images into a separate file can possibly improve performance for you. It can be done as Import records can import the container and ID data into a separate FileMaker file. I just don't see how that helps the basic slow performance issue.
This method should work to create copies of the image file in the designated location, but the details can easily trip you up. You have to correctly compute a valid path. The destination folder has to have permissions that allow you to write to it. Those are the two most likely issues to resolve. Note that this method exports copies of the image's files. It does not create a new FileMaker file of containers and images.
Okay so if moving to a separate file won't help with speed. Then what suggestions do you have to handle the images that are already saved in the container fields, that were not saved as references, to make references to speed up the database? Or how to setup differently so it speeds up the database?
You can use a variation of the script I describe in this thread to take a file physically stored in a container field, export it to a server and re-insert it as a store by reference image. I don't know if that will improve database response or not. You may want to try a smaller scale test with just a few images and see if there's a significant difference.
However you store your images, the data in them has to be sent by FileMaker to the client's computer--that's why moving the images to a separate file isn't likely to make any difference. The same bytes of data have to make the same trip over the same wires controlled by the same computers. I suggested in your other thread to check and see if you can edit the image resolution on these files to reduce their size without losing needed image quality. If so, that would appear to provide a significant improvment in speed if you find you have very high resolution images and don't need it. If you can change the path the image data takes, such as storing the images on a shared directory on your local area network instead of on the hosting companies server, the rate the data can be transmitted to your client computers may be much faster. For even faster performance, storing the images on the client computer would be even faster, but then you have to maintain multiple copies of the same images on all your client machines. That might work for a small number of frequently used, but seldom changed images, but would be a nightmare for larger numbers of images or ones that can be changed by the individual users.
So if I saved the image to the database file and not as a reference where is that file saved in the database? So i can decrease the image size. Bc its not the best way to do it locally as there are too many people who interact with the database and would have to update each other.
The file is saved in the container field if its not a "store by reference file". Export Field contents can be used to export the file back out of the database so that you can either re-insert the file as a store by reference file or so that you can edit the file before re-inserting it.
Thanks Phil for all your help on this.
I think I figured out at least the first step to speeding this up, but wanted to ask your opinion.
We have Questionnaires and notes that were written out on people from consultations. They have been scanned in and I noticed these are very large image file sizes. Would it help if I moved all those questionnaire and notes images to their own database file and just connected the 2 files with unique serial record ID so if you are in a persons record and want to see the original questionnaire or notes you just click on a button and that database file would open showing that person's questionnaire in a new window. This way these large image files are not saved/stored database file with the 13k records that is currently slow. Wouldn't that help speed up the database or would it still be slow because they are connected through the serial number?
Thx for your help on this!
You can certainly set up a small test version with a few of your image files moved into and see what happens, but I think the main factor here is the amount of time it takes to transmit the data from the hard drive where it is stored over the network to you client computer. Moving the images into a separate file doesn't really change that part of the process any.
If, on the other hand, you can find a utility that let's you take a folder of such image files and "downsamples" them all to a lower resolution (but hopefully still a level useful to you) before using FileMaker to re-insert them. The lower resolution images will make the trip from storage media to computer screen faster as they entail a fewer number of bytes of data to transmit in this fashion.
Thanks Phil. I have tested it and was able to decrease my file size from 1.40 GB to 713 MB just by moving those Questionnaires and Notes to another file and connecting the 2 files through a unique serial number. And I have found that it has sped up the database, however, I still it is not as fast as we need it to be. There is still about a 10sec delay from going to record to record. Then I decided to remove these 3 groups system we have setup that I took from the Template database Meetings. And the database started running great. However, I need these groups in the database and I need them to be displayed on each person's record showing which group they are apart of.
So I have a 2 part question. First do you have any suggestions of what I can look for in the scripting or layouts that could be slowing down the database. And secondly, does it speed up a database when all the fields possible are indexed or not indexed?