# Containers: Import from URL vs. Insert File

**URL:** <https://the.fmsoup.org/t/containers-import-from-url-vs-insert-file/5377>\
**Category:** Questions\
**Tags:** container\
**Created:** [April 13, 2026, 8:59pm UTC](https://the.fmsoup.org/t/containers-import-from-url-vs-insert-file/5377 "2026-04-13T20:59:19Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\
**Post date:** [April 13, 2026, 8:59pm UTC](https://the.fmsoup.org/t/containers-import-from-url-vs-insert-file/5377/1 "2026-04-13T20:59:19Z")

</div>

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:

```auto
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:

```auto
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](https://the.fmsoup.org/t/import-folder-vs-insert-from-url-error-1630/5376) for a "gotcha"

---

<div class="post-metadata">

**Author:** ![steve\_ssh](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/steve_ssh/32/160_2.png) [@steve\_ssh](https://the.fmsoup.org/u/steve_ssh)\
**Post date:** [April 13, 2026, 10:08pm UTC](https://the.fmsoup.org/t/containers-import-from-url-vs-insert-file/5377/2 "2026-04-13T22:08:23Z")

</div>

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

That said, with the release of the [Data File script steps](https://help.claris.com/en/pro-help/content/files-script-steps.html), 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).

---

<div class="post-metadata">

**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\
**Post date:** [April 13, 2026, 10:54pm UTC](https://the.fmsoup.org/t/containers-import-from-url-vs-insert-file/5377/3 "2026-04-13T22:54:05Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![steve\_ssh](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/steve_ssh/32/160_2.png) [@steve\_ssh](https://the.fmsoup.org/u/steve_ssh)\
**Post date:** [April 13, 2026, 11:49pm UTC](https://the.fmsoup.org/t/containers-import-from-url-vs-insert-file/5377/4 "2026-04-13T23:49:08Z")

</div>

> [@xochi](#):
>
> 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?

I believe that is exactly what I was doing in a few cases, though I note that the [Read from Data File script step](https://help.claris.com/en/pro-help/content/read-from-data-file.html) 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.

---

<div class="post-metadata">

**Author:** ![nils-w](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/nils-w/32/3392_2.png) [@nils-w](https://the.fmsoup.org/u/nils-w)\
**Post date:** [April 14, 2026, 9:42am UTC](https://the.fmsoup.org/t/containers-import-from-url-vs-insert-file/5377/5 "2026-04-14T09:42:35Z")

</div>

> **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.

---

<div class="post-metadata">

**Author:** ![steve\_ssh](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/steve_ssh/32/160_2.png) [@steve\_ssh](https://the.fmsoup.org/u/steve_ssh)\
**Post date:** [April 14, 2026, 1:26pm UTC](https://the.fmsoup.org/t/containers-import-from-url-vs-insert-file/5377/6 "2026-04-14T13:26:53Z")

</div>

> [@nils-w](#):
>
> This also applies to “Insert File” as you can set a variable as target and use “Set Field” afterwards.

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

---

<div class="post-metadata">

**Author:** ![daleallyn](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/daleallyn/32/819_2.png) [@daleallyn](https://the.fmsoup.org/u/daleallyn)\
**Post date:** [April 19, 2026, 7:01am UTC](https://the.fmsoup.org/t/containers-import-from-url-vs-insert-file/5377/7 "2026-04-19T07:01:24Z")

</div>

I'll add a side note (and hope it's not a distraction). I recently provided an example file for combining PDF files from container #1 and #2 into container #3 (appending separate PDFs) on the Claris Community board. On my first run through my script 'Insert File' did not allow for interactive viewing (showing only the PDF icon). That's not always the case, but it was this time (and I've encountered it before).

'Insert from URL' accomplished the same thing BUT allowed for the new PDF (appended) to be viewed properly in the container. Sometimes we encounter quirks. 😉
