Containers: Import from URL vs. Insert File

Questions
1

When using Container fields, hosted on FileMaker Server, where the container fields have External and Open Storage, there are several ways to import PDF files into the container, and they have slightly different results.

Insert File
[The Insert File script step behavior is very similar to what happens if you drag & drop a file onto a container field]

In addition to the PDF, you will also get a PNG created on the server.

A calculation field set to "GetAsText(containerField)" will show two files like this:

remote:foobar.pdf
size:792,612
PDF :Attachments/foobar.pdf
PNGf:Attachments/foobar.png

And if you look on the server, you will see two files inside the RC_Data_FMS container folder tree. The PNG file presumably was automatically created as a thumbnail image. If your PDF is small, don't be surprised if the PNG file is several times larger than the PDF file!

Import from URL
The Import from URL script step behaves differently. It seems to import only the PDF file, and does not create a separate PNG file.

A calculation field set to "GetAsText(containerField)" will show only the file you imported:

remote:foobar.pdf
size:792,612
PDF :Attachments/foobar.pdf

Which is better?

Personally I like the single-file version, as there's less clutter and it takes less disk space (often dramatically so if your PDF files are small).

Note that if you are using Insert from URL to get data into container fields, mind the URL format, see Import Folder vs. Insert From URL : Error 1630 for a "gotcha"

1 Like
2

Historically, I always preferred Insert from URL over Insert File.

That said, with the release of the Data File script steps, I started changing my MO to use these newer steps to get data into and out of a container field.

Using the Data File script steps generally requires more lines of code to get the job done well, because a few more steps are involved, and also I include error handling. I don't see the additional lines of code as a bad thing, but I understand that it could deter some devs.

The main advantage that I like about using the Data File steps is that using them breaks free from the attachment to the UI that is associated with the Insert* script steps.

Specifically:

  • Directly setting the field does not require that it be present on the layout.
  • Script triggers assigned at the layout level, e.g., On Field Modify, are not triggered by directly targeting the field.
  • No progress bar dialogs show (they sometimes may show when the script runs on client side).
2 Likes
3

Can you say more about that? are you basically using data file script steps to read a PDF file into a $variable, and then setting the container field to that variable?

4

I believe that is exactly what I was doing in a few cases, though I note that the Read from Data File script step supports using a field as a target, thus an interim $variable should be optional in many or most cases.

One point to call out for this approach is that there is an upper bound for what the script step supports in terms of how much data can be read at once. In all of the use cases that I needed to support, it was safe for me to make an assumption about the size of the file being ingested being well under the limit -- thus I was able to dodge that potential inconvenience.

If I were to need to support a binary file larger than the supported limit, then I think I would probably to go back to using Insert From URL.

Hope this helps. Disclaimer is that it's been nearly a year since I have had to implement one of these, so I am admittedly a bit rusty on the details.

1 Like
5

Specifically:

  • It is not necessary to have the target field present on the layout.

This also applies to ā€œInsert Fileā€ as you can set a variable as target and use ā€œSet Fieldā€ afterwards.

2 Likes
6

Thanks - that's a great point. I modified my statement slightly to better clarify my meaning.