ISO FileMaker Magazine

If you don't pay close attention to the fields you add to your record load in Claris/FileMaker, you might end up facing a transfer penalty, especially when dealing with container data. In many cases, your end users may not require the data from heavy multi-megabyte container fields. Nevertheless, every time the record data is loaded, that large container data gets included as part of the transfer.

Unlike SQL or a document database, where you can request only the necessary data, FileMaker provides the entire record, including all field data. Therefore, it is essential to create a structure which optimizes the utilization of containers. While I have previously covered this topic, this video offers a walk-through experience as I demonstrate how to implement support for a singular Files table, which can be used in multiple locations across a solution. I also discuss various options, such as one-to-one, one-to-many, and many-to-many relationships, when it comes to loading associated file data.

If you have ever wondered how to further enhance the speed and performance of your FileMaker solution, this video provides valuable insights into how you should likely structure your use of container fields. Understanding the concepts covered in this video will likely improve the performance of your solutions.

Just because you can create container fields doesn't mean you should create them whenever you think you need to store files for a specific table. There are possible solutions which, when implemented creatively, allow you to use one single container field for all of your solution's file storage. True, you may need container fields for other uses, but, when it comes to linking and storing the documents managed within your solution you can get away with one single container field within a single Files table.

In this video, I go over a super simple strategy for managing all of your solution's files within a very efficient storage model. We cover how to identify duplicates and simply prevent them from entering the system. Yet, any given file can be linked to any other record within the whole system.

Beyond this, you gain a very big advantage of being able to use the same scripts and layout elements across the whole solution. By adding a single relationship to any table which needs to manage files, we simply copy a selection of layout elements and then a simple paste get's of most of the way there. Want to know how to accomplish this efficient feat? Just watch the video and follow along with the sample file!

Even though your "database" includes the word "data", data isn't the only thing we categorize and track. We often need to track discrete files and FileMaker is perfectly adept at doing this. In fact, FileMaker's container field is ideally suited to store all kinds of different files.

The problem, however, is simply throwing a container field onto your layout is never really a good idea. If you allow users to simply drop anything into a container, then you'll surely end up with a collection of duplicate files and files which may not even need to be in the database.

The best method for properly managing uploaded files is to make sure you control what gets in and how it gets in. This isn't going to be handled with your simple addition of a container field to the same table tracking your contact information. This is best suited with a couple of gateway keepers. Filtering based on extensions and preventing duplicates are two methods you implement into a highly optimized uploading method.

In the associated video and technique file you'll have access to all the instruction and code needed to start you on the path to implementing the proper and ideal way for managing file uploads into a FileMaker database solution.