FileMaker Fever

FileMaker Advisor Magazine Rocks

I just renewed my subscription to FileMaker Advisor magazine. The reason I did with pleasure is that they've got all their articles for the last three years online. I didn't have to wait after I subscribed. The subscriptions person I reached by phone (800-336-6060) was able to walk me through the process and even change my username and password for me to what I preferred.

Now, instead of waiting 4-6 weeks for a paper copy of the latest magazine to arrive, I have access today to all the articles in the Dec/Jan 2005 issue!

Plus, I get a retroactive 3 year subscription for the price of one future year. The subscription for 6 issues in 12 months is $49. Given the massive amount of new and valuable information that is being generated by top FileMaker developers in this magazine, the money is very well spent.

If you want a quicker and easier way to climb the FileMaker 7 learning curve, FileMaker Advisor is one of the best information sources there is. If you aren't a subscriber or have let your subscription lapse like me, head on over and check it out.

FM7: Scripting in a Single File Environment

If you have a database with multiple tables in a single file, you will want to do things differently in terms of scripting. Here are some of the nuggets of advice I have on the subject:

Group your scripts by table. This isn't quite as simple as it sounds because scripts in 7 can easily do work in several tables. So, a reasonable rule is - put your script in whatever table group it starts in.

All of a sudden, you have a very long script menu. It's not fun dragging a script from the bottom to the top or even half way in one direction or the other. I hope a few keyboard shortcuts get added so we can move something quickly to the top. Or so that the scripts I import go in where my cursor is. Or so I can drag a group of scripts around and quickly put one table's scripts in a different position in the list. Some sort options would be interesting. But that's later.

Create a blank script with about 30 asterisks in it as your divider between tables. A bullet or 2 or the little hyphen divider isn't good enough when you are speeding up or down the list. You need something very easy to see.

Eliminate a lot of scripts such as all the scripts that individually go to a particular table (used to be an Open File script) or individually go to particular layouts. You can use script parameters in buttons and in scripts themselves to give a parameter to a subscript

Combine scripts. You used to have a script in file A that did a little work in A and then called a script in file B to finish the job. Why bother creating 2 scripts? Just pick the script among the 2 that is longest and add the script steps from the other script in and delete the shorter script you started with. Cleaner. Shorter script list. You'll have to decide how much of this demodularizing you want to do.

Modular is good. But long script lists aren't fun. I might wind up taking 8 scripts and condensing them down to 2-4. I don't have a modular script for its own sake - just because it does a discrete, logical part of the work. I l only create a separate script when that module gets used at least twice. And if it is 2 steps long, I'll probably just put those 2 steps in twice.

Modules really work when they are used a lot or they are long. You fix it or change it once and you are done. That's why I use single step scripts for page setup. If the script moves to a different environment with different printing requirements, I only have to fix the generic page setup scripts, not every report script I have.

Create generic scripts. With just a little thinking, you'll quickly find ways to use script parameters to create generic scripts. Generic - most used scripts - go to the top of your list. It saves dragging.

Give up on showing scripts in the menu for your users to use. You only get 10 keyboard shortcuts. And it's not going to be pretty if you show a lot of scripts. You'll need to narrow down to some most important scripts for that menu if you use it at all.

Consider using a two-letter table prefix in front of script names. Try this: "CT New Job". This script starts in the Contacts table and creates a new job. If you convert from 6 and import a lot of scripts from various files that are now all in one file, you'll find that some of your script names duplicate. You get New Job, New Job2 etc.

Once you add a table Prefix, you don't need to worry about duplicates anymore and get to use the name without the number at the end. Nicer. But do you really want to junk up all the script names with prefixes? I'm still just putting them in when I think it will help. Now the only problem is that my naming convention for scripts isn't consistent. Oh well...

eMacs as FileMaker Servers

You may want to see my post on eMacs over at my Studio Manager Bulletin blog.

1 Drawback to the Single File Approach

The single file approach in FileMaker 7 is very advantageous in many ways. Being able to control your security settings in one place is incredibly convenient. However, there seems to be one drawback. It's harder to segment out high-level security access to a particular part of your solution when it is all in one file.

Sure you can control layout and field access. But what about when you want to give someone the ability to create a new table? You have to somehow give them the ability to use the Define Database area. And that is an all or nothing proposition as far as I can tell. Either someone gets to be able to change fields throughout the file or not at all.

I'm hoping I'm wrong about this and will definitely post a correction if I find out otherwise. Corrections, anyone? I would like for there to be some gradations of access in field definitions. For example, you can let people have more privileges on new layouts. Could you do that for new tables, without giving away the store and allowing people to change existing database fields and relationships?

One solution is to allow the user in question to create the table as a separate file. Then, if desired the database administrator, could perhaps use FMrobot to bring the fields inside the big DB walls. The problem with this is that FMrobot only works on the fields and can't bring in layouts and scripts. And it is unlikely that there won't be need for some field definition and relationship changes after the initial try.

In a big, complex one-file database, you may just have to work around this limitation. There is probably a lot to be said for having a two-step process with end-user additions to the database.

You can give a user access to the Define Database area without them having Full Access. You do this by creating a script that uses the Open Define Database script step and make sure the script executes with Full Access. Because you have this option, you can use scripting controls to keep the lid on the database and retain control over management of Accounts and Privileges.

Cool FileMaker 7 Feature #1

I was pleasantly surprised just a minute ago to see that when I deleted a field that was used by a script, I got notified of that fact. First, it's good to be reminded that I've got a script that uses the field I want to delete. But second, the even cooler part is that FileMaker 7 tells you the exact script that uses the field. FileMaker 6 doesn't warn you at all when you delete a field used by a script.

Keyboard Shortcut: Opening Hard to Find Relationship Icons

Here's a tip from highly respected Marin County FileMaker developer, Ted Fehlhaber:

Finding and Opening the Relationship Dialog
Anyone whose tried working with a crowded Relationships Graph has run into the problem of finding the right relationships icon (those little boxes between Table Occurrences). Once found, it can be difficult to select and open the right one.

Here's the secret: If you select a TO that has only one relationship in a particular direction and hit the arrow key in that same direction, the first hop will select the Relationship icon. From there, Cmd-O (Mac) or Cntrl-O (PC) will open up that Relationship dialog. No more clicking around to try to select the right one.

Saying Goodbye to Global Glitches

Now that there is no longer a global field type in FileMaker 7, I find that I often forget to go to the storage tab and click the Use global storage check box. Then later I find out the hard way. Something doesn't work and after all sorts of investigations I figure out that my global field isn't really a global. I feel pretty silly and have wasted valuable time.

Something that helps me avoid this is naming my global fields so that they all group together. In FileMaker 6, I was happily putting an underscore in front of each of my global fields like this: _InvoiceNum. That conveniently sorted my globals to the bottom of the alphabetical sort order where my clients wouldn't stumble over them very often. In FileMaker 7, the underscore sorts to the top, so I've chosen to put a zg in front of the field name like this: zg_InvoiceNum. Not pretty, but it accomplishes my purpose.

I now can periodically just go to the bottom of my table field lists as I am developing and scan through the Options column of my globals to make sure they are all set as globals. Such a scan would be a great checklist item before turning over a solution to your client. I put it on my checklist.