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…
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.
