Month: February 2005

In my first really large-scale FileMaker 7 development project, I have created over 600 scripts. This is not something I am proud of. I would love to have 200. The more I use 7, the more often I consolidate script functionality into generic scripts driven by script parameters. You can save yourself a lot of scripting time by writing one script instead of 10 or 20.

Print Setup. Here’s a quick example. In FileMaker 6 and earlier, I always had a script for each print setup option. At minimum that would be Vertical Letter, Horizontal Letter and #10 Envelope. I then put a script step into each script that is supposed to print that performs one of these scripts.

No more. Now I use one print setup script and reference the single script with a script parameter to select the print setup option I want. In my single script, I use an If – Else If construction. Once you have an Else If section including the Print Setup step built, you can just highlight it and duplicate it as many times as you need Else If sections. Then just modify the script parameters and print setups right there.

If ( Get (ScriptParameter) = “Vertical Letter”
Print Setup [Restore; No Dialog]
Else If (Get (ScriptParameter) = “Horizontal Letter”
Print Setup [Restore; No Dialog]
Else If (Get (ScriptParameter) =#10 Envelope”
Print Setup [Restore; No Dialog]
End If

Go to Related Records. Here’s another example. In my FileMaker 6 solution, I had about 10 scripts in my Contacts file that would go to related records in other files. In my 7 solution, I replaced these 10 with a single script using script parameters with If – Else If again. I run this single script with the parameter as my code to tell the script which Go To Related Record step to run.

Reports usually have similar construction, so I can often lump several report scripts into one again using the If-Else If construction with script parameters. My FileMaker guru friend, Ted Fehlhaber, has been known to do all reporting with a single reporting script. I’m not that rigorous, but maybe he’s on to something.

I do have one *extra* script called Preview-Print-Return that I run at the end of my report scripts so that I can avoid entering the same steps over and over again. I also have an *extra* script that saves my place at the beginning of the report script and an *extra* script that checks to see if the user has enough privileges to run the script at all.

Extra generic scripts are generally scripts well spent. It’s the unique, single-use scripts that I look for ways to eliminate or consolidate. It’s worth pausing for a couple minutes now and then to see where generic scripts using script parameters can get the job done more economically.

I’ve been working with FileMaker 7 a lot these last 6 months. That’s every work day, several hours a day. And, I recommend that you go all out with the automatic audit fields that FileMaker 7 will keep for you. Put 10 fields into every table just to automatically track record creation and modification. Here is the creation half:

It’s often helpful to a user to see when a record is created and when it was last modified. You might see, for example, that this is a long-time customer. Or, an old customer who hasn’t had a new order in years. The magic word these days is context. And this kind of information provides context.

So much for the average user’s needs. As a developer, I also care a lot about trouble-shooting. Coming to the rescue in the rare cases (seriously) that my customers have problems they can’t solve themselves. These audit fields come in very handy when you are trying to figure out what happened. What went wrong?

Yes. User error is often the explanation – especially after a system has been working just fine for a long time. With audit fields, you can narrow down very specifically when something went awry and you can probably tell who was at the wheel when it happened.

In 7, you can not only get the user name of the person who created and last modified the record, you can get the account name. I like using the user’s full name as their account name. That way I can match the user’s account name to their employee record full name and set up their session with things like the contacts they’ve marked and can go considerably further than that if I want.

I want both user name and account name in case a user is at a different computer than usual or is signing in as an account name other than their own. Assuming an identity of sorts. Just as well have the extra info when it comes time to sorting things out. The date and time comes in handy also. It might be that at that particular date and time, a temp was in working. All part of the sometimes fun detective work that comes with the territory.

The New Timestamp field. I still haven’t figured out too many uses for this timestamp field type, but my guess is that it is great for calculating elapsed time that may cross over between days. The thing I don’t like is that I can’t get the field to be very readable in a list. The two sub-fields – date and time, don’t line up. For most purposes, I like the good, old-fashioned date and time fields better. But since it’s automatic, why not get it all?

Make sure to set those audit fields to Prohibit modification of the value during entry. You want to be able to rely on this information and don’t want it arbitrarily changed. Whenever you need a user-modifiable date, time or timestamp field, just create those separately even if you use the auto-enter creation field options for them.

One last thing. This is still just a thought, but I’m planning to try it out the next time I create a FileMaker 7 database from scratch. Create one or more template tables just for the field definitions piece perhaps. Then crank up FMrobot (on a PC) and have it create the 10 or so tables that you need – all with the one or more of your little templates. The basic template will have your 10 audit fields in it and a serial number field and a global for the serial number for starters. Until we can duplicate a table with the Define Database dialog, we can use FMrobot to help us out with the field definition piece at least.