Posts Tagged ‘filemaker’

Script Triggers: OnObjectValidate

Friday, August 15th, 2014

Note: This article assumes an intermediate familiarity with FileMaker Pro. Also, costs figures used in this article are made up.

FileMaker 10 gave us script triggers which let us call scripts when when users or scripts switched layouts and records, when fields are entered, modified, saved or exited. Script triggers revolutionized what we could do as users navigated through our solutions. FileMaker 11 introduced a new script trigger: OnObjectValidate. I had not used this trigger until I needed to solve two thorny issues in a recent solution. I thought these specific applications of this trigger would help others understand how to use it better.

You will benefit most from this article by first reading The OnObjectValidate Trigger written by Geoff Coffey of Six Fried Rice. Geoff’s excellent article helps you understand this trigger and its uses. My article gives two examples of this trigger’s use.

First Problem

In a large solution for a local printing company, customer service representatives, CSRs, select the specs for a print job in a portal. A customer orders 10 packs of forms and each pack consists of 100 sheets, padded on the back, glued at top with three holes drilled in the left margin. Each of these related specs must be linked with another record in a cost table that fills in the spec’s cost to produce. So choosing “Drilling: 3 left” for this product links to a cost table so this spec gets filled with a cost $1.64 to 3-hole drill 100 sheets or $2.38 to drill 10 of these packs at once. One problem we had to overcome is that old, legacy specs were often manually written, so when a product is ordered that hasn’t been ordered in the new system, customer service personnel must convert these legacy specs to the new format by selecting new spec types and details. To convert “Finishing: Drill 3-hole left”, the CSR must change “Finishing” type to “Drilling” and “Drill 3-hole left” detail to “3 left”. (Of course, we converted most of these prior to the system going live.)

The problem we had was that that specs normally are selected from a drop-down menu that populated the cost key value. Then the spec type, description and cost is auto-entered. When dealing with legacy entries we looked up the key value through a relationship using the type and description.

Trigger Order

Elements of a Database

Friday, April 22nd, 2011

Over the years in my consulting business, perhaps the most common way I find individuals handling information for their jobs is in Excel spreadsheets. Almost every one in every position needs to keep some type of information that is specific to their job. And Excel is a great place to do it. It is fairly easy to use, you can sort by columns and you can even share the information with Word to create form letters and address labels. But sooner or later most of us get to the place where we need a better way to use and manage our data, especially if we want to use our data in many different places or summarize and report on it.

In a later article, we will explore some of the ways FileMaker Pro and Excel can work together. Here I bring it up because if you are familiar with storing data in Excel, you will understand some of the basic elements on a database.


The Table

Data is stored in tables. An Excel worksheet is a table. A table is a collection of data about a specific thing, such as people or companies or products. My wife has a spreadsheet on which she checks off what groceries she needs this week. This is a table about groceries, not people invited to my daughter’s birthday party next month. This is important to understand: a table should only contain information about a specific thing, subject, or entity. Here is a table of people:


Rows and Columns

A table is made up of rows and columns. Each row represents one person in our sample table. Steve Linder is the Support Representative for Carp Corp. Ideally, no other row should contain Steve Linder’s name or information. On my wife’s grocery list each line contains one grocery item. So, a row represents one specific, unique person in our table above.

Each column represents an attribute of that person. Steve Linder’s position is “Support Representative.” His company is “Carp Corp.” Attributes may be the same for different people: Betty Brown also works for Carp Corp. Someone’s first and last names are attributes of that unique person, even though many people may have the same name. (This presents a problem when storing data about people, but we will talk about how to solve it later.)

In FileMaker Pro, a row is called a “record.” Each person in our database will have his or her own record. The attributes describing that person are “fields.” If our table were in FileMaker Pro, the columns are fields and the column headers at the top of our table are the field names. Here is what our table may look like in FileMaker Pro 8.5:



In FileMaker Pro, a file can contain many tables. Prior to FileMaker Pro 7, each file could contain only one table. Because of this, it was common for FileMaker developers to use the words “file” and “table” interchangeably. This has changed since FileMaker Pro 7, but you may still run across this in articles about FileMaker database design.


What is a database?

Friday, April 22nd, 2011

Let’s just start at the very beginning: What is a database?

In essence, a database is a collection of information. You may be surprised to learn that a database doesn’t have to be on a computer. It can be a cigar box full of business cards or an envelope full of coupons. But when your box starts filling up or your envelope bulges with coupons, it becomes difficult to find the right card or coupon. So you may one day organize your cards in a Rolodex or your coupons in an expanding file pouch with letter tabs. Now your information is stored in a “database system”.

“A database system is a set of procedures, devices, and rules for managing the information in a database.” (from “Learning FileMaker Pro 8.5″ by Jonathan Stars Wordware Publishing; Palno, TX) So, a Rolodex is a “database system” because it takes your cigar box full of business cards, puts them on the Rolodex spindle and organizes them alphabetically.

Let’s say you spend a few hours one Saturday organizing your cards in your new Rolodex by last name. You proudly take your full spindle into the office. You enjoy looking up people’s phone numbers so quickly. One day you remember a saleswoman named “Sandra” you promised to call, but you can’t remember her last name. You think, “She worked for some office machine company, but I don’t remember which.” You could flip through your Rolodex and pull all the cards from office machine companies, or every card with a first name “Sandra”. You can see that this is not very efficient.

Most of us think of computers when we hear the word “database” because they are excellent devices for storing, retrieving, finding and reporting on data. If you had your cards entered into a computer-based database system you could search for every person with the first name “Sandra”. Chances are, in a second or two you would end up with fewer than a dozen names and one would probably stand out or jog your memory as the one you had promised to call. FileMaker Pro is one of many computer-based database products available for computers running Macintosh or Windows.

Next, we will look at the basic elements of a database, then we will focus on how these work in FileMaker Pro.