As developers one of the hardest things for us year on year is pushing the limits of what we write and can feasibly do as developers. This leads us to get stuck in habits, whether that is code related in terms of syntax, structure related or interface. We like to do the same things repetitively because we know they work and stepping into the bounds of new material would mean having to debug the process from scratch and test it within a user environment which none of us enjoy.
Typically after we’ve gone through some extent of training to learn how to use FileMaker, or any language for that matter, we stick to the same way of doing things, maybe because we only know that way, and learning a new way comes from talking to someone that has done it before and has a different way to you which you either adopt or believe yours is better and leave by the wayside.
For me this came recently in the form of a method of record creation called “Pivot Create”. This method is technically simple to pull off after understanding the fundamentals of it, but because of how it works it seems daunting at first glance.
Pivot Create is a method of creating new records and populating related data quickly and easily. There have been white papers written on the topic but it’s not something that FileMaker make obvious within their FileMaker Training Series as it’s too complex at that level so not many ever get to hear about it. The way it works is by creating a Global Field within the schema table you want to create from. Next you create a relationship between your new field and the primary key field, which has to be an auto enter field, on your other table. The final piece of the puzzle in the relationship is setting the “Allow record creation across this relationship” setting on.
The way to then create your record is to write data to any field in the table across that relationship. When your global field is blank it assumes you want to create a new record, so putting data to a field in that relationship first creates the record and then sets the data. This can either be done directly on a layout or as part of a script, however if you’re creating new records on mass or multiple times across that relationship then you have to clear it every time you want to use it. There’s more to this method, however these are the very basics.
My own apprehension of using this method came during the development of a project we had been working on. I learnt of its existence but was too worried about implementing it in a hurried environment where I didn’t have the information I could have had to be able to implement it properly. Looking back now, however, I’ve come to realise that had I implemented it, it may have saved us some performance issues and would have made maintenance easier.
Another example of getting stuck in old methods can be found when we look at the new themes and styles methods of creating a UI and UX in FileMaker 13. We can still fall back into the habit of setting an object to have a unique set of attributes, rather than creating it as a style and then being able to re-use it. The latter method is far superior; we use less memory to store designs and decreases the amount of processing that has to be done, even more important with WebDirect, but it’s still so easy to forget about these seemingly minor changes.
In the end there’s no absolute right or wrong way. However, there are ways that would lead you to better results, and better performance. Being scared to try something new just because it’s not something you’ve done before will only lead to not being able to program and code better in the future, and pushing boundaries is the best way to learn.