Found sets are what make a database a database. Without found sets, a database wouldn't be much more than a relational spreadsheet. Found sets determine which records print, sort, export and preview. Practically all features in FileMaker are structured by the found set. Sometimes you have to break the found set, current record or sort order, unbeknownst to the user. Maybe the user is running a script that does something very complex that requires destroying one of these elements. The user doesn't care how difficult it is to program a feature. The user just wants a smooth experience. If you have to change the found set, current record or sort order, you had better restore it. The only person who should modify the records showing is the user himself. In this followup article, I will demonstrate how to permanently save found sets.
Entries in this blog
Imagining a database without found sets is like picturing a bird without feathers. It just doesn't make sense. Found sets are the essence of a database. If there were no found sets, you would need to sort your entire list of records and scroll to find a record. To say the least, this would be an inefficient process... especially if you have more than a thousand records. Found sets are what make a database a database. Not only do finds allow you to locate a specific record but they also enable you to perform actions on a subset of records like importing, exporting, printing, sorting and looping, to name just a few. With such a far-reaching effect on the processes in FileMaker, found sets often need to be preserved and/or reloaded. "Save" is a good word to describe what I'm going to talk about in this article but there are all kinds of saves. Some saves are temporary and other are more permanent. Being able to work with different save techniques is crucial to applying the best method to the task at hand.
How you design a FileMaker solution often depends on how it will be accessed. Is it a single-user solution running off the local hard drive? Is it a multi-user database with all users accessing from the LAN? Maybe there is a occasional remote access from someone at home? What if the company is distributed across the United States and needs a completely cloud based solution? Maybe some users won't always have an internet connection? It could be that some users don’t even have FileMaker? These are some important questions to ask yourself or your client before beginning the design phase of a solution.
One of the most important concepts to grasp hold of tightly, when moving from the design of single-user to multi-user FileMaker solutions, is record locking. It's a fairly simple concept to understand. It just prevents two people from editing the same record at the same time. The complex part of record locking is programming your scripts to manage record locking. In this article, I'll start by defining record locking, demonstrate what causes record locking, show you how to test for record locking without hosting your solution and finally how to trap for record locking. I'll also throw in a few examples for good measure so you can measure your newly found skills in the context of a real life scenario.
I took a different technology approach than every other person out in cyber land writing FileMaker blogs. I actually created my own FileMaker database to manage my content. Go figure! I could have taken the easy way out and used canned blog software but FileMaker is perfect for this job. Besides, I'm a firm believer in eating your own dog food. It just makes sense since FileMaker is the career I have chosen. Let me tell you a little bit about why I chose FileMaker as blog back end and reveal some of the key features that make it a better choice for me than off the shelf software designed for the masses.
The relationship tab in Manage Database is not an ERD (Entity-Relationship Diagram). Sometimes it looks a lot like an ERD but it is so much more. An ERD represents the structure of your solution while the relationship graph contains structure as well as what I like to call techniques. Techniques are relationships that allow a feature to function properly, not provide structural integrity. You might create a filtered portal as an interface option or use a multi-key relationship and a script to drill down through records to create found sets or even a conditional popup menu that requires a non-structural relationship to operate. With a discussion of anchor-buoy relational design as the main thrust, this article attempts to impart a better understanding of relationships.
I'm no SQL expert but I know when, and when NOT, to use the ExcecuteSQL function. ExecuteSQL is not for creating replicas of portals, despite the numerous examples floating around the internet. It's also not designed to replace the built-in FileMaker find feature, even though it seems to replicate the search abilities of find mode. In fact, there’s really nothing ExecuteSQL can do that a relationship can’t do, it just can do it without a relationship. In other words, it resolves Relationship Graph clutter but, only under under certain circumstances.
The most common non-technical question I get is, "how do I become certified" or "how do I study for the certification test"? It's a good question. If you're taking the test seriously then you need to study, right? Not only does it cost a few hundred bucks to sign up but it's an important milestone in your FileMaker career. I mean, why wouldn't you want to have that feather of certification in your proverbial FileMaker hat. It tells clients you have achieved a level of competency that only a couple other thousand people in the world can lay claim. It sets you apart from the rest of the FileMaker crowd in a way that can easily be identified by a logo.
Logical functions are some of the most important and widely used functions. Think of decision making when considering logical functions. They enable you to decide if a formula will return one result or another. Which fork in the road will the formula take? Testing for true or false is often referred to as boolean in the FileMaker interface so get used to the terminology. While it is common for amateur developers to overuse these functions, if utilized properly, they are extremely powerful. Logical functions include Case, If, IsEmpty and Choose, to name a few of the most important.
The old saying that time is money is more than just a saying. The faster you can develop a project, the more money you can make as a commercial developer or, the more time you can devote to other projects as an in-house developer. Being as efficient as possible is the key to success. That's the primary difference between amateurs and experts. Balancing speed with quality is challenging though but, can be done. As you gain experience, quality and speed will both increase naturally, especially if you strive to improve in the primary areas listed below.
Steven Blackwell almost always starts a phone call with "greetings and salutations" and often ends with another famous quote, "keep the faith". I've never asked what he means but I'm pretty sure it's not religious. Steven Blackwell loves the FileMaker platform and he likes other people who feel the same as he does. Keeping the faith is just trusting in the FileMaker platform. I'm also pretty sure he didn't start using this quote when he started developing FileMaker solutions. It's just how he sees everything in life. When he believes in something, he gives it his all. I appreciate that about him so much. But, let me introduce you to him first since you may not know him as well as I do.
I like to compare the process of creating a database solution to the construction of a house. If you start by hiring a contractor, you probably won’t get the house of your dreams. The first step is to hire an architect. You tell the architect you want five bedrooms, three bathrooms, a man cave and a swimming pool and he designs a house based on your specifications. The architect then shares the plans with you so you can validate his design. Maybe you decide to change a few things. The architect takes your input and create new plans. The process can go back and forth until the plans are satisfactory. The same process is necessary for proper database design so let me walk you through the steps to success.
The biggest mistake I see amateur developers make is using relationships and calculations to create reports. They work great in single-user mode with test records. Put that same solution in a multi-user environment with thousands of records and performance starts to grind to a halt. Add a WAN into the mix and it degrades the speed even further. The same is true for dashboards which often use the same techniques. The aim of this article is to teach standard reporting methods for beginners and seasoned developers alike. While the topics include mostly beginner and intermediate subjects, we'll dive into a couple advanced examples at the end.
So, what's wrong with the default window name given by FileMaker? Imagine a user of your solution has multiple windows spawned on a small screen and goes to the Window menu to select the desired window. Without good window management, all he sees is "CONTACTS", "CONTACTS - 2", "CONTACTS - 3" and so on. With good window management, you can make it easy for users to quickly find the window they want without cycling through all of them.
Close scripts generally aren’t very important in a FileMaker solution, especially a multi-user solution, but Open scripts should be employed on just about every solution created. Open scripts setup up your solution for the user, making it easier to use. In the following paragraphs, there are many examples of common Open script snippets you can include in your own solutions but Open scripts are as varied as there are developers and the solutions they create. The ideas in this chapter are just a starting point but the discussions that ensue will deepen your FileMaker theory.
When you start writing scripts for the first time, they are fairly simple and can be understood quickly. Even weeks or months down the line, the name of the script should be enough to identify the functionality. As your scripts increase in complexity, you need to consider modular scripting. Modular scripting is essentially writing your scripts in pieces and connecting the pieces with a parent script.
I normally don't like to directly advertise products and services on this blog but there is real FREE content here. What I'm going to do is provide inline videos from part one of my new FileMaker 16 three part video series. I'll discuss why the lessons are important and provide some insight as to how they fit into the whole of the videos series. Happy FileMaking!
In this article, multiple scripts will be created to accomplish the same task. This may seem silly at first but, it's an important exercise to learn the best approach to a problem. If you are new to this concept, you should actually build the different scripts to cement the concept in your mind. I've been using this methodology for a very long time so it just comes naturally. In fact, most of the work occurs in my head. In time, the process will become second nature and you will find yourself building more efficient and capable scripts.
I was asked to write an article about my experiences, troubles, pitfalls and recommendations to those starting out with FileMaker. I find many times, and this applies to any industry, when experts help beginners, the experts forget what it was like to be a beginner. While the expert is generous with his or her advice, although perfectly accurate, it sails over the beginners head. The beginner just doesn’t have the experience and tools to digest and disseminate the advice offered. On many of the FileMaker help forums, I see many people who get a copy of FileMaker, jump right in to making their first database and quickly run into trouble and frustration. I know their pain, because I made some of the same errors. Hopefully some of the tips, based on my experience will help the beginners avoid my errors.
The new release schedule, designed to get fresh versions of FileMaker to the public faster, is in full swing with the release of FileMaker 16. It took the FileMaker 16 development team just one year to program a fully featured upgrade with changes to Pro, Go, Server and WebDirect. A truly amazing feat. While FileMaker 15 was a platform upgrade, with few visible changes to Pro or Advanced, FileMaker 16 focuses back on the desktop application we all love to program. Everything begins at the desktop so it really should be the center of attention in every FileMaker release IMHO! I think this version will leave experienced developers very satisfied.
FileMaker is an incredibly versatile and scalable platform, but it is genuinely unique in the way it allows you to solve real world problems quickly, efficiently and super cost effectively. I work for a company that manufactures water softeners (the best ones actually) and I was asked to solve a particular problem we were having in diagnosing rare cases of abnormal operation in the field. In this case study, FileMaker was a perfect fit!
One of the most common FileMaker fallacies is a web browser client will save money. I hear it almost weekly from the people who contact me directly. I get it. Everyone wants to save money. But, just because a web browser is free doesn't mean it saves you money. This article will consider specific points about why a FileMaker client provides a better experience for the user than a web browser at the same price.
What is FileMaker Pro scripting? It can be defined as automation, a macro and even a programming language. FileMaker Pro scripting has elements of all these definitions. The original purpose of scripting was to automate the mundane task of printing a report. Since it repeats most of the items under the menus, it can also be considered a macro language. Yet, it is so much more! With logical branching, it can even be considered a programming language. The FileMaker Pro Script Workspace is a beautifully designed environment that enables you to create a solution as good as any commercial product on the market. This scripting primer well tell you everything you need to know before you write your first script.
In the last few years, I've subscribed to the KISS methodology (Keep It Simple Stupid). Call it wisdom or humility, I'm not sure which. All I know is, after over two decades in the FileMaker market, I've discovered the simplest solution is most often best for my clients. It costs less and performs better, in most cases. I know all the tricks, having practically wrote the book on the subject, but there is a time and a place for complex methods. What I'm here to convince you is, choose complicated techniques carefully.