Highlighting insight, performance and collaboration
Wow! InspectorPro 6 is finally here. Can’t even believe it. It was such a massive undertaking. Lots of great new things and many improvements. Really proud of this release. In the immortal words of the late Steve Jobs… “This is our best version ever”. The focus has been to deliver something that is truly useful. We hope this version helps you make informed decisions about your solutions.
One of the first lessons I learned with FileMaker is that of context! Layouts, reports, calculations, scripts, and so on all act from the perspective of a single Table Occurrence (TO) — the “context” — pulling in data from related tables as needed. Generally, the record set being acted on is the set of records in that context table occurrence or a found subset thereof. There are a few exceptions to this, however, and today we’re going to explore one of those.
A few years ago, I worked on a FileMaker project where the client told us that every week they need to import about 7,000 rows of data that represent some information that this company uses. And every week there might be some modified records, some records that don’t show up any longer, and some new records that hadn’t already existed. For this example, let’s just call it this data “Products”.
Over the years that weekly information grew to about 12,000 records per week. This PRODUCT table itself had 35 fields of data. So, without a way to manage the duplicates, every week lots of redundant data would need to be imported.
Now more than ever we’re relying on Perform Script on Server (PSoS) to maximize FileMaker performance, so naturally a need arose for a way to proactively monitor how many concurrent scripts are being triggered. This type of logging helps us see if we’re reaching our maximum limit, or have a rogue script eating up processing power.
As a FileMaker developer you probably spend a big chunk of your time writing scripts. The new Script Workspace in FileMaker 14 is going to help you in a big way. It’s a breath of fresh air and at first glance it might seem trivial in that we now have colors and we actually can have white space, but there are many other productivity improvements that lurk beneath the surface.
Just so we don’t forget where we came from, here is what we have had until now:
And compare the same script in the new Script Workspace:
For the longest time I thought field labels were something special and there was some sort of connection between the label and the field. So if you have ever created a new field and put that field on the layout with the label to the left of it. Then 10 seconds later you change your mind and decide to rename the field. Presto your label has also been renamed.
But if you changed the label in any way. For example you have a field called “FIRST_NAME” and your rename your label to “First Name” then change the field name to “FULL_NAME” your label will still read “First Name”.
For the longest time I thought that the text label had some special flag on it. But it turns out … wait for it! Its the Field that has special powers. It has a “FORCE FIELD” ( I couldn’t resist ). So here is something you can experiment with. Create a file with one field in it. Call it BLUE. Then in layout mode duplicate the text labels and organize them as an ellipse around the field. as shown below. Rename some of them and leave some of them just as they were duplicated.
When you delete a field that calculations or scripts depend on, FileMaker provides great warnings.
FileMaker is not so graceful about providing similar warnings when deleting scripts. It’s usually impractical to know the potential consequences of deleting a script without a solution analysis tool like InspectorPro. It might be easy for you to remember the connections in a solution you just started solo work on, but it’s a completely different matter when it comes to a legacy solution that has been around for years (or days, for some of us!), or a solution with several developers each working on different interdependent components. It’s impossible to remember all the references to any particular script, even if you created all of them. InspectorPro tracks all this information for you with great level of detail so you can maintain solutions with confidence that your actions will not have any unintended consequences.
I recently moved to OS X Yosemite, and once again repeated the annual cycle of wondering whether or not my existing solutions will be compatible with the new version. I’ve loved using AppleScript to trigger OS X Notifications from FileMaker since they were introduced in OS X Mavericks, but they stopped working as soon as I installed Yosemite. I still check system version so I can show a FileMaker Custom Dialog for users who don’t yet have that feature. But Yosemite’s version number broke my check!