A: You're correct that the only option for inserting QuickTime movies into a container field is to store a reference to the actual file. If the file is moved, renamed, or deleted, you won't be able to play it.

A good way to sneak around this restriction is to embed the movies in the database as files (using the Insert File command rather than the Insert QuickTime command). As we'll demonstrate, you can then create a script that, on-the-fly, exports the file and re-imports it as a QuickTime movie. This approach should provide the user experience you're looking for.

Imagine you've embedded a file called Movie1.mov into a container field named myContainer. In its current state, users can't play the movie from the database. However, because it's embedded in the container field, it travels with the database when you send it to the employees.

Create a new field, moviePlayer, as a container field with global storage and place it on top of or near myContainer. Next, create a script that exports the file from myContainer and imports it back into moviePlayer (as a QuickTime movie).

The script ends up looking something like this:

Set Variable [$myOutputFile ; "file:" & Get (TemporaryPath) & "movieTemp.mov"]
Export Field Contents [myContainer ; "$myOuputFile"]
Set Variable [$myInputFile ; "movie:" & Get (TemporaryPath) & "movieTemp.mov"]
Go to Field ["moviePlayer"]
Insert QuickTime ["$myInputFile"]

The script begins by setting a local script variable, $myOutputFile, to a text string that represents the full file path, prefixed with "file:", which FileMaker Pro understands to denote a relative file reference. There's no need to create different paths for different platforms using the "filemac:" and "filewin:" formats; the generic reference works just fine. Notice the second part of the path string is the function Get (TemporaryPath). This function returns the full file path to a temporary directory FileMaker Pro maintains and has access to. You'll dump the file to this directory and point back to it with another container field.

In the second line, the script exports the contents of myContainer as a file called movieTemp.mov in the temporary folder. If necessary, you could also preserve the name of the original file simply by using GetAsText (myContainer) in place of the hard-coded movieTemp.mov.

Now that you have the file on the user's hard drive, it's time to import it back as a QuickTime movie. The format of a file reference for inserting a movie is slightly different than a regular file reference: instead of the "file:" prefix, movies must have a "movie:" prefix. (You can verify this detail by looking at the options in the Insert QuickTime script step.) Because of this requirement, the third line of the script creates another variable that references the exported file as a movie. With this in place, all that remains is to insert the movie into the moviePlayer field.

When this script finishes executing, the global container will contain a reference to the movie and the user can play it. The original container field still contains a "file" version of the movie. You've simply created a way to export the file in such a way that you know exactly where it is and what it's called. Remember this technique when working with container fields, because there are many variations that may come in handy for manipulating how or where you store objects.