ISO FileMaker Magazine

Perform Script on Server is the one step which will change how you develop FileMaker solutions FOREVER. Yes, I said that with all caps! This is exciting!

There's so much power in how it can be used, that it truly is a game changer. This is fundamentally why the web is so popular. It works like this.

Your client, a web browser, makes a request to some beefy server and it wrangles the data and then reports back with the compiled results. This is essentially what this new script step does, but with all the power of what FileMaker can do.

Until you start using it, it "seems" like it's just "another feature". Changing the way you think about FileMaker development, using PSoS for short, is inevitable. If your solutions are stuck in versions prior to 13, then you might want to beg, borrow or steal (ok, not steal) to start using this feature.

With PSoS, you can import hundreds of thousands of records in mere seconds. You can send hundreds of thousands of emails without ever seeing a spinning waiting indicator. You can update hundreds of thousands of records with lightning speed or generate a hundred page report as a PDF within minutes instead of hours.

This video provides all the critical know-how in order to start working with PSoS and it will get you going fast!

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.