ISO FileMaker Magazine

FileMaker solutions don't really care where your data comes from. They've long had the ability to reach out into ODBC & SQL sources of data. So long as the connection is fast and stable, users really don't know, or care, where the data is hosted.

With the addition of Claris Studio, data can even be hosted within a NoSQL database such as MongoDB - although we can't, as of yet, structure any of the data other than through the Claris Studio interface.

This also means you can use the same External Data Sources feature to split up your single solution into as many files as desired. It's a perfect tool for segmenting out complex systems such that smaller sub-systems are both accessible but separate. This allows you to plan for more variety in the use of your technology and apply better security protocols.

Even when you get to the level of simply separating a single FileMaker solution into two files of UI and Data, you'll find some benefits. If your data file is a separately hosted file, then your UI file can also be hosted or optionally local to the device the user is using. This video provides a How-To of converting a single FileMaker file into the Data Separation model. While there are few gotchas with a simple solution, it's beneficial to know how to troubleshoot a more complex conversion. Of course, starting out with a Data Separation mindset can be beneficial as well.

For many FileMaker systems, the number of concurrent logged in users, especially those who will hit issues with record locks, is often very low. Typically, these types of systems are used within the local area network and you just ask the offending user to unlock the record. However, with the number of remote users logging into a system through the WAN, a variety of things have had to change. The way you architect a database system can't necessarily take the same approach as was done before.

As a FileMaker developer, you should now consider the remote user and plan your system accordingly. Fortunately, this approach can be taken at any point in the life cycle of a FileMaker system. You can retrofit or plan from the outset to use a very creative way of avoiding record locks. Quite simply, you provide each user with their own personal file.

If you're familiar with using External Data Sources within FileMaker, then this may be common ground for you. If not, then you'll find a ton of useful information within this video. If your users are accessing a system from across the globe, then using the know-how here will help alleviate a lot of connection stress and struggles because it's a method of data collection and transfer which directly emulates what users do when they interact with a standard web based application. Need the benefits of speed and performance? Look no further than Avoiding Record Locks.

Recently, FileMaker released its iOS App SDK for FileMaker Pro. This new technology for FileMaker developers allows for both consultants and solution developers to create client or customer specific solutions which can run on iOS without having to install FileMaker Go.

Given the speed with which a FileMaker solution can be built and deployed, the knowledge of using the Separation Model of deployment becomes a valuable tool for creating agile solutions. Easily updated and easily deployed.

When it's possible to update a FileMaker solution via the click of a button, you can iterate very quickly and both fix issues and enhance functionality. Clients and customers get to realize the benefits of having a custom solution while being able to take advantage of the powerful features which FileMaker Pro and FileMaker Server offer.

If you've never used the Separation Model, then there's still a big benefit to knowing that you can create a stand-alone FileMaker solution for use on a mobile device. Being able to update this solution is a critical component in the development of software using FileMaker Pro.

In this video, I showcase not only the technology, but the know-how necessary to update any given FileMaker file which exists on a device - be it a desktop, laptop, iPad or iPhone.

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.