FileMaker Fever

Analyzer 4 is a Great Debugging Tool

Analyzer 4 came out in September but it's taken me a while to adjust to its differences and discover its power. It runs about $400 for a brand new copy and less as an upgrade. I've been a long-time user of Analyzer and have always found it valuable to help me find errors in systems and fix them.

Analyzer 4 is different enough that I didn't immediately understand how to use it. Unfortunately for me, I wasn't really using it much the first few months I had it. I'm in the final stages of perfecting Studio Manager 7 and necessity has compelled me to learn it. Here's what I found: (1) it's not very hard to learn and (2) once you do, it's a real winner.

The famous red dot - the problem report - is what is helping me right now. I run it and it finds all the syntax errors throughout Studio Manager. Studio Manager has 12,500 layout objects - mostly buttons and fields and other layout objects, 642 scripts with 4,681 script steps, 44 base tables with 249 layouts and 171 relationships. This sheer volume provides lots of room for little mistakes.

One especially cool thing is that there are no false positives. If you get a count of 500 errors, you've got 500 errors - actually more because Analyzer can't find your logical errors. When I saw the 550 errors I got in early December, I thought, oh there are mostly false positives in there. Wrong!

I'm down to 7 scripting errors and about 120 layout object errors. I have about 600 scripts as I mentioned in my last post and probably 30,000+ layout objects. I can eliminate all of those 120 last layout object errors today. And then I'll get back to the final 7 scripting errors some of which I'm debating other issues about so don't know whether to fix, change or eliminate them.

Here are my top 4 favorite features

Problem Reports with Red dots work great.

Lets you find for Script names which is a life saver when you have lots of scripts in one long list.

Hot links between elements take you where you need to go fast.

Compares analyses to each other - this really helps when you aren't sure which version is which or you need to replicate the changes you made elsewhere.

One last thing, you get much faster at using it with a few hours of use. You gradually learn how to very quickly find what's wrong and fix it by using the various features of the program. Clearly, Vince Menanno was using it and improving it incrementally along the way. That's why you appreciate it more and more with use.

The Economics of FileMaker 7 Scripting

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.

FileMaker 7: Recommended Audit Fields

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.