ISO FileMaker Magazine

Just because you can click the Create button to add a new container field doesn't mean you should do it. In fact, you might want to consider never adding a single container field to your main solution's tables. "Really?", you ask. Yes, because there are many advantages to segmenting a solution into multiple distinct parts. Most media, images, video and audio, is considered "heavy data" and that data comes with a big cost.

It may be that you're unfamiliar with how you can best structure your data within FileMaker. With images, you're often better served by handling that data in a very specific and dedicated way. This video, and the associated technique file, shows you how to approach the situation of handling images. It also addresses the display of those images. For the sake of images, you certainly need to see the image for the value it provides. However, you rarely need to transfer the full image which was captured or imported.

Watch this video in order to gain a full understanding of how it may be best to both store and view your images within a FileMaker solution.

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.

While FileMaker may promote the low-code/no code aspects of FileMaker Pro, there's a lot to be said about knowing how to design a great system as opposed to thinking you'll end up with one by default. Especially, one which will perform under load and scale to the degree which FileMaker can.

This type of knowledge is learned and simply won't come out of the box when you just start adding fields to your database. If you need to store images, or any type of heavy media, then it may not be a good idea to carelessly start throwing container fields into your tables. In fact, there's a whole bunch of details to know about FileMaker and how it transfers data on a record level basis. As well as knowing what can be done to optimize your storage of container based data.

While you'll want things to be easy for your users for adding media, and you'll also want to build a system which will be easy to maintain and update. That's what this video is all about. An optimized approach to container storage and making it easy on yourself when you're going to be working with these types of solutions in the future.

When first learning about database development, and how to store large files such as media, archives and documents, I was introduced to the concept of a BLOB (Binary Large OBject).

At that time, I wasn't using FileMaker Pro as of yet but a database called FoxPro. The concept of FileMaker's Container fields, as places to store BLOBs, came so much easier than having to convert a file into another format which can be stored within a SQL data store - which is what you have to do with some other database systems.

In today's modern computing world you need to be familiar with how to encrypt things and how to transfer them between various services. This video will overview the Base64 encoding functions, the Crypt functions and all the other Container related functions. If you'd like to understand how and where the container functions will help you out with working with containers then you'll likely find what you need in this video.