ISO FileMaker Magazine

When developing within FileMaker, there are often times when I'm surprised at how much "figuring out" is required to solve a problem. In this video article I provide a great deal of information about a problem I was having with managing a recurring import of some inventory data.

The data being imported was constantly changing and came from an external source where only a few fields are controlled by the user. With the original FileMaker system, it was structured in such a way where the "clean slate" approach was taken.

The "clean slate" approach, which you can likely guess, is one in which you simply wipe all previous data and simply import a whole new set. While this works well with small record sets, the more you import, and the larger the data set, the more of an impact, in terms of waiting time, you'll feel. You also lose the benefits of being able to assign your own internal key values and maintaining those within the schema.

So, what's the answer to the question of a recurring import where a significant percentage of data may not change? It's record modification tracking. You need to track which records were modified in order to know which should be post processed or updated by the logic of your solution.

This video and the sample file demonstrates exactly how I approached the problem and includes valuable information which I am sure will make you a better FileMaker developer. If you've never understood why you might want to use a "hash" for comparing data, or if you've thought you should really look into performing scripts on the server side then, by all means, jump into this video. It has a ton of great stuff to learn from!

For me, it's always been one of those itches I could never quite scratch. You know, the fact that in order to show some of your user interface graphics you needed to store these graphics within your database - along with your data.

In fact, it's pretty much accepted that you create container fields, many times within a dedicated table, to store graphics and resources.

The issue I had with this approach was not that it needs to be done, but the fact that the user interface graphics were not separated out from the rest of my data. I wanted to be able to simply "draw" graphics onto the layout.

Well, this itch can now be scratched with FileMaker 13's new Base64* set of functions. While you still need at least one container field in order to render your graphics, the new additions have reduced the number of fields in total.

Watch this video to gain a full understanding of how this works and just how easy it is to integrate into your own solutions!

Simply creating a single FileMaker file to store your data is a perfectly fine way to start your solution. However, the first few times any number of users start complaining about the workflow taking too long, is when you may need to evaluate your architecture.

For sure, FileMaker Pro is a very capable platform. Like any thing else in the world of tech, there are less efficient implementations and highly optimized solutions. A knowledgable developer will known how to squeeze every bit of performance out of the environment they've chosen to develop within. The same holds true for FileMaker as for any other programming language.

In this video, I walk though some of the most common and also some of the more exotic deployment models you can use with FileMaker. Essentially, it all boils down to this. Knowing that FileMaker does not care where the data is. If you can point to it, and FileMaker can see it, then it's up to you as to how you structure things. We're not just using computers now, we're using smartphones, tablets and who knows what else will be coming. Touch sensitive wallpaper within our homes of the future? Watch this video for a sense of how it's possible to vary the deployment of your FileMaker solutions.

Having access to one of the more recent and most prevalent UI patterns within FileMaker is extremely empowering. Using Popovers and portals, it's now possible to create solution wide menu systems which can be used for navigation, actions or whatever you see fit.

When you combine global variables, with the Virtual List technique and popovers, you can significantly decrease the amount of time it would normally take to maintain even a moderately complex menu system within a FileMaker solution.

It only takes a bit of creativity and foresight to implement solution wide popover menus which can be easily changed. These menus can all leverage the same elements and dynamically change based on any number of variables.

In this video, I walk you through the components which make up this powerful technique and reveal a number of powerful core methods for making it happen. Whatever level you're at, there's something to be gained by watching this video tutorial about popover menus.