3 Replies Latest reply on Aug 29, 2012 11:41 AM by philmodjunk

    FMP12 upgrade, container fields and OLE



      FMP12 upgrade, container fields and OLE


      I'm really excited to see how FM is using the new enhanced container fields with external storage.  I got my new copy of FMP12 today and started to play, but ran into problems pretty quickly.  We use FM for an internal purchasing system, generating dozens of Purchase requests daily.  One of the most useful aspects is the ability to store PDF's of all of the associated paperwork (quotes, invoices...) in container fields (embedded).  But FM is quite inefficient when embedding PDF's.  Our database file sizes ballooned quickly to over 10 GB even though we only added 500 MB of PDF's.

      I converted the file over to the .fmp12 format easy enough.  I ran into problems when I tried to convert the container fields over to external storage.  Of the approx 2400 records with embedded PDF's, only one successfully converted over to the new external container field.  The one that did, was the one record I created after I converted the orginal database over to the .fmp12 format.  Checking the transfer log, I get over 2400 lines of

      .......  [Record ID 2407, field Attachments::Attachment] Skipped non-transferable data: OLE object

      Will I not be able to take full advantage of the external storage/enhanced container fields, using my existing databases, which is the primary reason for wanting to do the upgrade in the first place?

      These databases are about 7 years old,  currently running on FileMaker Server Advanced 11, hosted on Windows Server 2008 R2,  all clients who interact with the container fields are all Windows 7 FileMaker Pro 11 clients.  Even though I use FMSA, no aspect of these databases use IWP, XML, PHP or ODBC/JDBC.  I do not use an external connections to these databases, they only interact with FMP clients.

      Another issue I found, is secondary, but really kinda reduces the "ease of use" factor for the new version of FileMaker.  I notice that any of the new records with container fields, when I drag the PDF into the container field, it no longer shows a thumbnail of the PDF, and more importantly, I can no longer just double click on the thumbnail (lack thereof) or file icon to open the PDF in Acrobat or Reader.  You can on any of the records that were existing previous to the conversion to .fmp12.  I know it the new fields can be accessed by 'exporting field contents' but when users are generating a dozen or so records a day, and accessing well over a hundred of these container fields a day, even the minor amount of time it add really starts to add up, not to mention all of the bogus copies of the files that get created because you have to 'download' a new copy each time you want to access it.

      Thankfully I am working on copies of the databases, in a test server enviroment.

      Are there workarounds to my issues, or should I hold off on upgrading my users and server?

        • 1. Re: FMP12 upgrade, container fields and OLE

          FileMaker 12 does not support OLE. Given how poorly it supported it in 11 (You can't export OLE objects from container fields, you can only manually open them with a double click one by one...), that may actually be a good thing over all, but creates a major migraine of a headache for your database.

          I wish there were an easier way, but the only way to get your OLE embedded objects to work with Filemaker 12 is to re-insert each and every file into your database as a file or PDF object. Given that you can't use a script to export the OLE objects, this becomes a major undertaking unless you can figure out a way to insert the files from their original locations without trying to export them from the container fields using a script of some sort...

          In Filemaker 11, in windows, drag and drop from outside Filemaker did an Insert (OLE) object action. In fileMaker 12, the same action does an Insert File option and without the "store a reference" option selected--so this embeds the file in your database, there is no thumbnail of the PDF showing and it can't be opened by double clicking.

          In both Filemaker 11 and 12, the only time (other than for OLE objects) that you could open a file in a container field by double-clicking it is when Insert File with "store a reference" selected is used to insert the file. Double clicking a container field when Insert Picture or Insert without "store a reference" was used has never worked.

          Now we have new options in 12: You can use Insert PDF if you optimize your container field on the layout for interactive contact. (See the data formatting tab on the inspector.). This produces not only a thumbnail of the PDF, but you can actually page through the PDF right in the container field. But you can't double click to open the file.

          One option is to use Insert PDF from your Insert Menu to insert the file, using the "store a refrence" option, then use a calculation field that returns a "container" field type to extract the file path from your first container field, replicating the Insert File/store a reference format. I think double clicking that calculation field or a script with Go to Field [Select Contents will open the file from it's current location.

          • 2. Re: FMP12 upgrade, container fields and OLE

            First off, I can still open pdf files in Acrobat by double clicking on the thumbnail in the container field, but I can only do that in container field that existed before the database was converted to the .fmp12 format, so FileMaker 12 does have the ability to open file embedded in container fields by double clicking on them.

            I over stated the imporatance of seeing the actual thumbnail. It's nice to see, but not that important.

            If you do as you suggest in the last paragraph, and insert the PDF with Store a reference selected, does the all end users still need to have access to the stored location? or does FM handle it through the enhanced external storage feature?

            My whole goal in the container fields is to not have to use Windows Explorer or the Mac finder.  My users want to be able to simply drag and drop the PDF to add it to the container field, and they need to be able to either double click on the container field, or a button to directly open the file that is in the container field.  This is something that we have been able to do since we started useing container fields about 6 yrs ago in FMP8.  Admittedly, it is a user behavior issue, and a slight annoyance if my users cannot do this, but since I have mulitple users, interacting with these container fields upwards of 100 times each per day, it starts to add a significant amount of time, creates a lot of duplicate files, and certainly increases the annoyance factor.  The enahnced container and extrernal storage function of FM 12 may make the database more stable and efficient for dba's and programmers, but for end users, it's more of a downgrade in functionality.

            • 3. Re: FMP12 upgrade, container fields and OLE

              It is my understanding that users will not need direct access to the file if the external storage option is specified for the container field.

              I don't know if the resulting container field will allow you to open the file by double clicking the container field or not. I suggest experimenting to see. I don't think it will as the double click sends an event along with the file's file path to the user's operating system to get it to open the file. This would require direct access to the file--the very thing you are trying to avoid as a requirement by specifying external storage.

              Note that there are several ways to use scripting to make things more user friendly:

              When a user drags and drops a file into a container field, you can use a script to export it to temporary items and then re-insert it to get it inserted with the options you want.

              Export Field Contents can export a copy of the file to temporary items and then open it. Thus, you can use a button to open a file in a container field--this creates a temporary copy, however, so edits made to the file after you open this copy will not be retained unless you use a script to re-insert the file from Temporary items.