ISO FileMaker Magazine

As technology advances and becomes as critical to our digital lives as water is to our physical well-being, we must be keenly aware of whether that "water" is tainted with harmful elements that could harm us.

This sentiment applies not only to your health but also to your technological security concerns. For most technical systems, we may be inclined to assume that "big tech" — meaning the creators of the software or technology — will automatically make things safe for us. However, there may be risks that neither the provider nor the user recognizes until they surface.

Recently, the FileMaker landscape has been impacted by several critical security findings, making it essential for you to understand your level of exposure.

In many cases, threats may be mitigated by measures within your control. However, in some instances, upgrading is the only viable solution. Many FileMaker systems still rely on versions much older than FileMaker 19, following the old adage, "If it isn’t broken, don’t fix it." This time, however, it is very, very broken. Older versions of FileMaker Server, if publicly accessible, can be hacked in ways that conceal any traces of intrusion. In this case, using outdated versions is a risk you can't afford unless you're prepared to accept that your system is essentially open to anyone willing to find it.

Being able to develop and test your solutions within a FileMaker Server environment is the ideal scenario. You can test Perform Script On Server, external binaries, and plug-ins that perform a variety of tasks. Essentially, you can perform all the necessary tasks in a real solution.

When you develop your FileMaker solution locally with a single copy of Claris/FileMaker Pro, you not only face limitations in what you can test but also risk the possibility of a crash. While running FileMaker Server on your local machine is a satisfactory solution, the next step is being able to run multiple versions of FileMaker Server without the need for multiple uninstall/install scenarios.

This video showcases my return to using Docker Desktop on an M1 Mac Studio ARM-based machine. Previously, I had to stop using Docker and resort to a full virtual machine when I switched to using Apple Silicon. However, with the release of an ARM-based version of FileMaker Server and most plug-ins being available for the ARM architecture, we are now able to use Docker Desktop again. The trick lies in learning how to use containers. This video provides a great opportunity to learn a new skill. If you want to run multiple variations of FileMaker Server on your M1 or M2 Mac, this video has what you need.

Being able to develop locally, as if the data and the server was right there on your local machine provides a nice advantage. You know how the solution will work when hosted, you can develop and test PSOS scripts effectively, and you're generally protected from client crashes. Plus, you're fully mobile if need be - it's all on one machine.

This is where hosting your FileMaker solutions locally becomes a big advantage. This video showcases what I consider to be the Big 3 of local hosting. 1) You can install FileMaker Server right onto your local machine within the local OS. 2) You can run FileMaker Server within a virtual machine or 3) you can now use Docker locally to host your FileMaker data.

No matter what you choose, it's beneficial to emulate that server environment and host your data locally as you develop. This video will provide you with some of the details about making that happen and which one you might choose to go with.

Prior to FileMaker 13 we never even had the option of performing scripted tasks where the data actually exists. The processing of a script, client side, always had, and still does, make a full round trip for all kinds of these processing activities. Many times, FileMaker does it's best to optimize whatever is being done, but it's still not as fast as executing certain things directly on the server.

With the addition of Perform Script on Server we gained a REALLY BIG performance boost by being able to perform most any script on the server.

While there are still various limitations, such as the number of simultaneous server side scripts, it's absolutely something that any serious FileMaker developer needs to know how to use.

One of the biggest issues with running server side scripts with Perform Script on Server is the fact that you need to know what's happening when the script is running, how to troubleshoot and most importantly, how to replicate the current user context. That is, the proper layout and the exact same found set to be used for processing the data. This video specifically covers how to restore the user context for processing a found set of data. If you're interested in making this process happen as quickly as possible, then using Perform Script on Server is what you should learn to use.

La tecnología WebDirect de FileMaker nos permite que cualquier usuario pueda acceder a nuestra base de datos a través de un navegador web. Dicho de otro modo, no es necesario que tenga una licencia de FileMaker Pro en su ordenador.
Para poder compartir mi solución de este forma, necesito hacerlo a través de FileMaker Server pero, ¿por dónde empiezo?, ¿cómo activo WebDirect?, ¿qué tengo que modificar en mi archivo?
En este vídeo aprenderás lo esencial para empezar a trabajar con WebDirect.

FileMaker Server es el software de servidor que se utiliza para compartir información de forma segura con grupos de usuarios de FileMaker Pro Advanced, FileMaker Go y FileMaker WebDirect.
Aprende en este vídeo todo aquello que necesitas para poder instalarlo sin complicaciones.

Si nuestra aplicación está hospedada con FileMaker Server, podemos acceder a ella a través del menú Archivo -> Abrir remoto. Esta opción puede ser un poco liosa para algunos usuarios. En este vídeo aprenderás a crear un "abridor" que te permitirá un acceso rápido a tus archivos remotos y que, además, podrás distribuir a todos los usuarios de la solución.

Whether you're a hobbyist developer or a full-time professional, it's important to make sure your development environment is both stable and reliable. Unless you're in the process of learning a new environment, not that many developers are keen to spending a bunch of time re-configuring their development environment.

The worst feeling in the world, while developing, is one of instability. Having that looming fear that your application or file may crash at any time is not a happy place. It's like you're constantly looking over your shoulder waiting for the next FileMaker crash. For FileMaker development, the solution to this problem is to always develop using FileMaker Server.

When FileMaker Server is within your development environment it provides crash protection, automated backups and other learning benefits which you simply won't get if you only upload your FileMaker file to a host and simply work that way. If you're still developing locally with just a copy of FileMaker Pro Advanced then this video should be especially appealing.

Also, if you're a developer on-the-go and you can't be tied to a local network, and may not have WAN access, then running a local FileMaker Server is a great solution. One possible issue is that FileMaker Server has be structured for a production environment and not for a development. You can, however, with a few setup changes, make your local development machine use FileMaker Server in order to facilitate the ideal development environment.

When FileMaker 13 was released, one of its sleeper features was Perform Script on Server. Yeah, developer’s recognized it, but didn’t really know how to value its power.

With the subsequent release of FileMaker 14, and FileMaker Go 14 in particular, the advantages of Perform Script on Server simply can’t be overlooked by anyone creating solutions within FileMaker Pro.

If your FileMaker solution has any number of users, beyond a very small number, then the performance gains can be quite significant for certain tasks.

While certain script steps like Export Field Contents cannot be used with Perform Script on Server, there is a wealth of functionality which can be harnessed through the use of server side plug-ins. Because of what you can do on the server side, there are few, if any limitations. Need to communicate with other web services via ODBC, SQL, REST, SOAP (pick your acronym)? Want to send bulk HTML email using an online service like Amazon’s SES mail sending? Need to automate a routine import which normally task just a bit too long?

Using PSoS is simply a matter of understanding what’s happening server side and knowing how to troubleshoot. Fortunately, this video will provide you with all the know-how!

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.