11 Replies Latest reply on Sep 3, 2009 9:20 AM by philmodjunk

    Database Slowing Down with Pictures (which will work better?)

    awhurley11

      Title

      Database Slowing Down with Pictures (which will work better?)

      Post

      Hi again,

       

      So we recently upgraded to FileMaker Pro 10 which solved a previous issue I had in terms of getting images into our directory. However, now when we start to add photos, Filemaker is seriously chugging along. I know there are two options, one which adds the photo directly into the Database file, and another which only references it. Right now some are actually added and some are references due to my inability to be decisive about this.

       

      In terms of speed of the program, which would yield a faster response time? Actually adding the images in and having a larged sized Filemaker file, or making them all references to the images? Remember, speed is the concern here, and not necessarily the size of the file.

       

      Thanks! 

        • 1. Re: Database Slowing Down with Pictures (which will work better?)
          mrvodka
             Keep a reference to them.
          • 2. Re: Database Slowing Down with Pictures (which will work better?)
            philmodjunk
              

            Another option to consider: How much image resolution do you really need? If you can downsample the images to a smaller resolution, Filemaker, using either storage option, will be faster. Of course this may not be a pratical option for you, but if you can make it work, it might help.

            • 3. Re: Database Slowing Down with Pictures (which will work better?)
              awhurley11
                 Thanks for the help guys. I really should have thought about downsampling the images before, that was an oversight on my part and I think I can do that.

              However, there's no way to say for example, have FileMaker not draw the photos from their referenced files until I choose to print, or preview them? Because right now it's automatically loading the referenced image - I was wondering if there was a way you can bypass that until another time.
               
              Thanks again! 
              • 4. Re: Database Slowing Down with Pictures (which will work better?)
                ninja
                  

                If that's what you're after...not loading unless you want to...why not simply duplicate your layout.

                 

                Have a layout without the containor showing at all (ie. field is not on the layout), and one with it showing.  A button called "View Image" would perform a GoToLayout function and shift you to the layout with the containor showing.

                 

                When you print, simply have your print button perform a script that goes to the image viewing layout first, then prints.

                 

                Is that what you mean?

                • 5. Re: Database Slowing Down with Pictures (which will work better?)
                  etripoli
                     If you're on a Mac, you can use 'sips' at the command line, the Scriptable Image Processing System, and/or AppleScript to downsample the images after placing a reference to them in FileMaker. 
                  • 6. Re: Database Slowing Down with Pictures (which will work better?)
                    awhurley11
                      

                    Ninja wrote:

                    If that's what you're after...not loading unless you want to...why not simply duplicate your layout.

                     

                    Have a layout without the containor showing at all (ie. field is not on the layout), and one with it showing.  A button called "View Image" would perform a GoToLayout function and shift you to the layout with the containor showing.

                     

                    When you print, simply have your print button perform a script that goes to the image viewing layout first, then prints.

                     

                    Is that what you mean?


                    I would do this, except I'm inputting the images to each person's record now. This means I would need the field visible on the layout right? Or can I still import a photo to a record's Photo Field even when the field isn't present? 

                     


                    • 7. Re: Database Slowing Down with Pictures (which will work better?)
                      mrvodka
                         You can use a utility layout and keep your main layout without it. Most developers have utility layouts in their system that are only accessible by them.
                      • 8. Re: Database Slowing Down with Pictures (which will work better?)
                        ninja
                          

                        Agreeing (I think) with Mr vodka,

                         

                        I would have a total of three layouts, all based on the same table and showing the same records:

                         

                        Layout1: Utility layout that only I can see...doesn't need to be pretty, just needs all the fields present so I can see what's going on.  This layout is optional, but often handy.

                         

                        Layout2: Quick Use Layout.  This has all the fields that the users need EXCEPT for the image containor.  It also has the button I mentioned before with a GoToLayout function that sends you to layout3

                         

                        Layout 3: In all ways identical to Layout2, save two changes.  A) this layout has the containor field showing the image, B) this layout has the same button, same place, different background color/shade but this button performs GoToLayout and sends you to layout 2.

                         

                        End functions: in layout 2, you can scroll quickly through records and do whatever is needed without the delay for image load.  If you want to see the image, you click the button and end up on layout3...but the user won't know that, it'll just look like the image loaded and the button changed color.  When done looking at the image, I can "hide" the picture by clicking the button and ending up back on layout2 and work quicker.

                         

                        If you're "inputting the images", you would be working in layout3...with the containor showing.  If you're trying to speed up getting to the record desired, work in layout2.  They are the same record, just different layouts through which you view the record.

                         

                        Just another option available to you...you know your need best. 

                         

                        • 9. Re: Database Slowing Down with Pictures (which will work better?)
                          philmodjunk
                            

                          Ninja's post is triggering an idea that might be cool for this:

                           

                          Create a layout with nothing but the container field located in the upper left corner.

                          Use New Window to pop up this layout as a floating window sized just big enough to display the picture.

                          Use a button with script to pop this up on demand from Ninja's "quick access" layout.

                          • 10. Re: Database Slowing Down with Pictures (which will work better?)
                            ninja
                              

                            Cool Phil,

                             

                            But keep in mind that you'll run headfirst into window resizing jitters again...on a PC anyway.  Happens every time with the new window feature.

                             

                            Cool idea, though.  Sorta like a small preview pane instead of a blank area.  I like it.  You would need a stripped down image to keep the speed up, but you covered that already up above.

                            • 11. Re: Database Slowing Down with Pictures (which will work better?)
                              philmodjunk
                                

                              Yeah, I'm aware of the "window jitter issue". You can add code to minimize this on a windows system--especially if you set your DB up so the main window is always maximized.

                               

                              Right after the new window step add:

                              Move/Resize Window [ Name: Get (filename) ; Height: Get ( ScreenHeight ) ; Width: ( ScreenWidth ) ; Top : 0 ; Left : 0 ]

                               

                              (I used Get (filename) to specify the name of your main window that just twitched )

                               

                              Then, script the close of the pop up window to include

                              Close Window [Current Window]

                              Adjust Window [Maximize]

                               

                              You can script closing the window with a button on the pop-up layout or by using FMP Advanced custom menu tools to replace the standard close window command with a call to perform this script.

                               

                              Another note: you usually need to include a pause step in the script that pops up the window to make it "modal". With the paused script, the user can't accidentally "lose" the popped up window by clicking on the background window to bring it to the front.