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.
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.
FileMaker Meetups: Seattle, Portland, Santa Clara & LA
Beezwax’s Vincenzo Menanno is hitting the road this week to visit our FileMaker colleagues across the West Coast, talking about “FileMaker Collaboration, Performance and Insight with InspectorPro”. Vince will be presenting our latest research, development and product offerings to FileMaker Developer Meetups in Seattle, Portland, Santa Clara and Los Angeles. If it weren’t a 4-day work week, who knows what other cities we’d be visiting!
Here’s a schedule of events, dates and times — and a Big Thanks to Meetup organizers for your help in hosting Vince’s presentations.
In the transit-planning universe, planners and economists often get excited about 5 minutes shaved off of a 30-minute bus ride. The individual rider might shrug at a mere 50 minutes saved per week, but the planners and economists multiply that 50 minutes by the number of people who ride that route during a typical week and see something much bigger. There’s a compounding effect: it doesn’t take long before these small gains in efficiency add up to a huge economic impact overall.
What’s this have to do with FileMaker, you ask? Well, the new FileMaker 15 is now available, and the inevitable question comes up “should we upgrade?” Sometimes the best discoveries when a new version of FileMaker hits the shelves are the “sleeper” features and under-the-hood improvements. In the most extreme cases, these go entirely undocumented by FileMaker Inc.; such is the case with the improvements in portal performance that accompany the FileMaker 15 release.
Portals being a very important part of the FileMaker user interface, anything affecting their performance, good or bad, is going to have a major impact on the user’s experience. Users of a database application often spend large chunks of their workday in the application, so, like that 5 minutes shaved off the bus ride, small efficiencies add up through the same compounding effect. And, as you’ll see, this one is a “big” small efficiency!
No, I’m not talking here about the new, threaded portal rendering (aka “inline portal progress bar”) that is a key public feature point for FileMaker 15; I’m talking raw performance optimization. So impressive is this optimization, in fact, that I never even saw the new inline progress bar during my testing!
We develop FileMaker applications because we want a place to store information for the long term. We track events, tasks, contacts, finances—FileMaker can track almost anything. To update information, the application might ingest a spreadsheet. You usually don’t want spreadsheet rows to feed directly into data tables, since you risk calamity should the columns be mismatched with target fields; you bring data into the application, validate it, and (often) massage it before updating regular data. After you process temporary data, you need to get rid of it.
In the past, Delete All Records represented the only option for removing large numbers of records. After a user performed a function such as the import mentioned above, the system would process the imported data, and then a progress bar would appear, informing the user that a (sometimes large) number of records was being deleted. You don’t want a user sitting through a slow process or worrying about losing information.
Removing the Wait and Concern
FileMaker 15 offers a means of reducing wait times and anxiety for users. Enter the new Most Dangerous FileMaker Command for Developers: Truncate Table. The word, “truncate” means to shorten or cut short; Truncate Table deletes all of the records in a table—the current table or one you select. “Remove Table Data” or “Delete All Records And I Mean It This Time” would be a more accurate name. (The name comes from a SQL command.) The only data not removed from the table when Truncate Table executes are values in global fields, with the exception of global container fields, which lose their values. Truncate Table will not delete child records–you still need Delete All Records for that requirement. Users must have full access privileges to run Truncate Table, which also distinguishes the command from Delete All Records.
We found that, when the Truncate Table script step is called either directly from a script or using Perform Script on Server, the user doesn’t see a progress bar or a message about deletion, and doesn’t have to wait—the records disappear right away.