FileMaker tips, techniques, and news.

By Jeremiah Kincaid  Posted on  September 2nd, 2009  in  FileMaker

Using FileMaker Table, Layout IDs in Scripts and Calculations

We've all been there: You're going through an existing FileMaker solution, updating data infrastructure to align with the current project's goals and you realize you can't change the 'Service' table occurrence name to 'Order' because you've statically referenced the 'Service' table occurrence name in various scripts and calculations using the built-in FileMaker function Get(LayoutTableName). "Oh well," you say, "I can still change these Service layout names!" Except that you've also statically referenced the layout names with another FileMaker function, Get(LayoutName). Fortunately for you, there's a reliable way to reroute these references:

  1. Run an HTML Database Design Report (DDR, for short) of the current solution in a copy of FileMaker Pro Advanced.
  2. Open up the resulting HTML file in a browser of your choice.
  3. Use the browser's find function to isolate all instances of the word—in your case, 'Service'—and change these instances to use 'Order' if they're the partner-in-crime of a Get(LayoutTableName) or Get(LayoutName) statement (e.g. "Get(LayoutTableName) = "Service"").

Unfortunately for you, this takes time and could result in transcription errors. There's gotta be a better way, right?

No, there isn't. If you've been implementing FileMaker database solutions with references to static/hard-coded table occurrence or layout names, the only way you will be able to change said table occurrence or layout names is to drudge through your solution with DDR in hand and manually change the references to their new names. Then and only then can you feel secure in changing the table occurrence or layout names themselves.

Of course you could just change the table occurrence or layout names and ignore the possibility that things will break if the old names are hard-coded in scripts or calculations. Personally I don't know any developer who would feel comfortable taking that risk.

An Ounce of Prevention

Cures are generally much more tedious to apply than preventions. Using a DDR to change references is a cure. What we really want is a prevention. Is there any way to reference table occurrences and layouts in scripts and calculations as to allow a developer to change names without breaking anything? Why yes there is: Use FileMaker internal IDs.

When you create a new table occurrence or layout (or most any FileMaker object, for that matter), FileMaker references that particular table occurrence or layout internally with an ID. It doesn't use the table occurrence name or the layout name. What this means is that you can always isolate any table occurrence or layout you want if you only knew the corresponding FileMaker internal ID.

Grabbing a List of FileMaker Internal IDs

FileMaker provides a handy-dandy set of what are called design functions that spit out information about the structure of an open database file, information like a list of all field names, script names, etc. in the current file. Included in these functions are functions that list all table IDs and layout IDs in the specified file, each one separated by a carriage return. To illustrate, if you have a FileMaker file with three layouts—Order, Invoice and Contact—with IDs 3, 1, and 2—respectively—using the function LayoutNames(Get(FileName)) will return the three layouts in order of layout number, which is to say, the order in which they are organized under Manage > Layouts :

Contact
Order
Invoice

Now, the same file will return the following list using LayoutIDs(Get(FileName)):

2
3
1

Notice that the layout IDs are not the same as the layout numbers. In our example, Contact has a layout number of 1 (because it's the top most layout under Manage > Layouts), but a layout ID of 2. Order has a layout ID of 3 but a layout number of 2.

The practical use of all of this is that you want to extract a FileMaker ID from a given table occurrence or layout name and then hard-code that ID into scripts and calculations. The difference between hard-coding a name versus a FileMaker ID is that an ID will never change while a name could change, as you may want to alter the name of a table occurrence or a layout in the future (e.g. our earlier example of 'Service' to 'Order'). The only way an ID will change is if you delete that object and then replace all instances of that object with a new object under the same function and name. Let's say you have an Avery 5160 label print layout called "Avery Labels" with the internal ID of 5 that suddenly becomes corrupted. You delete the corrupted layout and create a new one under the same name. But because this is a new object, the FileMaker internal ID is different than the original layout's ID. For illustration purposes, let's say the new layout's ID is 140. Although this new layout has the same name, same look and same function as the original one, the internal ID is different. Thus, if you hard-coded the original Avery layout's ID in any scripts or calculations, you will have to manually change those references to the new layout's ID, a task which we are trying to avoid by using IDs in the first place. However, the likelihood that you will have a corruption is much, much smaller than the want/need to change names in the future, and so using IDs are still best practice.

Returning to our modest-sized solution of 3 layouts, we want to extract a layout ID from its corresponding layout name. The easiest way to do this is to build a custom function, as you don't want to reinvent the wheel, so to speak, every time you need a layout ID. You can build the logic to extract an ID based on a name once in a custom function and then use the custom function throughout your solutions.

Or, you could borrow someone else's custom function and never have to invent the wheel yourself! We highly recommend you visit Brian Dunning's FileMaker Pro Custom Functions website, not only to extract IDs from names, but also to browse for any other potentially useful functions. We've gotten ourselves out of a few jams copying the free custom functions offered on this site.

In particular, Ulf Carlsson's custom function GetLayoutID("current") will allow you to extract a layout ID of the layout name you pass in the "current" parameter.

Doing It Yourself

Some of you will probably feel the need to build the function yourself. In that case, all you have to know is how FileMaker's design functions LayoutIDs and LayoutNames organize their lists. Both the IDs and names are organized by layout number, and so because you know both lists are organized exactly the same way, all you have to do is find the position of the layout name in the LayoutNames list and use this position to extract the ID from the LayoutIDs list. We'll spare you the gruesome text parsing details, unless you actually want to know exactly how to do this. If so, feel free to contact us.

IDs in Action

Once you have a GetLayoutID([SomeLayoutName]) in place, it's time to put it to use! Because you are replacing instances of Get(LayoutName) with GetLayoutID, you need a way to dynamically determine the layout ID of the current layout. All you have to do is combine the two functions:

GetLayoutID(Get(LayoutName))

This will dynamically return the layout ID of the current layout, which is in the same spirit as dynamically returning the layout name of the current layout using Get(LayoutName) only.

In most cases, you'll be rewriting a Boolean statement such as this:

Get(LayoutName) = "Contact"

So far we know what to replace the left side of the equation with: GetLayoutID(Get(LayoutName)). To get the right side, you'll need to know the ID of the layout you want to hard-code into this Boolean statement. The easiest way to find this ID is to:

  1. Navigate to that particular layout.
  2. Open up Data Viewer (Tools > Data Viewer, a feature only available in FileMaker Pro Advanced).
  3. Click the Watch tab.
  4. Add the expression GetLayoutID(Get(LayoutName)).

The expression result should be the ID of the current layout, which is the one you want to hard-code. You can then ensure this is the correct ID by running the script in which you used the GetLayoutID function.

Developers Are Human, After All

If someone tries to read the ID code you just wrote, she/he will have no idea what layout that actually is, unlike a name, which usually provides some sort of context. Layout ID 3 means nothing to both you, who just wrote the script, and any developer down the line who reads or rewrites your script. To add a bit of context to your GetLayoutID statement, add a calculation comment with the name of the layout, like so:

GetLayoutID(Get(LayoutName)) = 2
//Contact

The Reverse: IDs to Names

There are times when you want to convert an ID to a name. To do so with layout IDs, you would need to duplicate the GetLayoutID custom function and basically turn the function inside-out: change all uses of layout ID with layout name and layout name with layout ID. Again, the FileMaker design functions LayoutNames and LayoutIDs are sorted in the exact same manner; all you need to do is find the position of the ID or the name you are trying to extract. If you have a layout name and want an ID, you find the layout name position in the LayoutNames list. If you have a layout ID and want a layout name, you find the layout ID position in the LayoutIDs list. Like before, we'll spare you the text parsing details.

Table IDs

Like LayoutNames and LayoutIDs, FileMaker provides design functions for table names and table IDs: TableNames and TableIDs. Unlike LayoutNames and LayoutIDs, TableNames and TableIDs include more than just tables: they are lists of table occurrences. Therefore we have a slightly more complex situation on our hands.

Because TableNames returns a list of TO names, not plain ol' table names, this basically means that if you have used the function Get(LayoutTableName) anywhere with any hard-coded TO name, you won't be able to change the TO name without breaking something in the solution, unless you change the hard-coded references. What this also means is that you can change the actual table name which the TO is based off of and be safe, UNLESS there is a TO that has the exact same name as the actual table. If so, FileMaker will automatically rename the TO when the table is renamed, and in that case, if you have hard-coded references that haven't been changed, things will break.

Once you understand that FileMaker returns lists of TOs, not table names in their design functions, everything else works exactly like layout IDs. Both TableNames and TableIDs are sorted the same way (alphabetically, in case you were wondering, and in case you were wondering further, no two TOs can have the same name) and thus once you know the position in one list, you can extract the corresponding information from the other list. Just duplicate your GetLayoutID custom function and change all references of layout name to table name and layout ID to table ID. Duplicate your new GetTableID(TableName) custom function and reverse the references to table name and table ID to obtain your GetTableName (TableID) function.

Putting It All Together

Using table occurrence IDs and layout IDs in scripts and calculations will allow you the freedom to rename TOs and layouts as you see fit without any logical repercussions. As a FileMaker developer who tries to build solutions as modular as possible, referencing IDs instead of names just makes sense. We all want our get-out-of-jail-free cards: who knows who will be poking and prodding at our solutions 10 years from now or how the solutions will evolve over time. IDs give the flexibility to induce needed and unforeseen change in the future.

Download
Download the FileMaker Table and Layout IDs in Scripts and Calculations File
Please complete the form below to download your FREE FileMaker file.
FileMaker Experience *
Terms of Use *
OPT-IN: I agree that I am downloading a completely free FileMaker application file with no strings attached. This file is unlocked, and I may use it for my business or organization as I see fit. Because I am downloading a free file, I agree that I should receive occasional marketing. I understand that I can OPT-OUT of these emails at anytime.
Jeremiah Kincaid thumbnail
Jeremiah Kincaid

Jeremiah is a Certified FileMaker and Salesforce Developer who has been with DB Services since 2007. A Purdue University graduate, Jeremiah earned dual bachelors in Chemistry and Philosophy while simultaneously learning FileMaker. His educational background and natural smarts gives him the ability to be successful both in the trenches of scripts as well as in collaboration with co-workers and clients. A rarity, indeed.

FileMaker 18 Certified Developer
FileMaker 17 Certified Developer
FileMaker 16 Certified Developer
FileMaker 15 Certified Developer
FileMaker 14 Certified Developer
FileMaker 13 Certified Developer
FileMaker 12 Certified Developer
FileMaker 11 Certified Developer
"We were actually able to add more features than we thought would be possible within our budget. We always experienced a ‘can do’ attitude and DB Services was incredibly patient and easy to work with."
Courtney Hartman
Art Director
"The new FileMaker custom website interface is very user-friendly and easy to follow for our clients. In addition, it is much faster than the old Instant Web Publishing (IWP) interface. Thank you and all the others who have helped us out at DB Services. I am very grateful for the excellent service you provide us. Its nice to know we can call you for help if we have an issue."
Wayne Capek
President
"We needed a solution that would simplify the administration of our responsibilities under our contract with the State of Indiana. We have seen a dramatic increase across the state in the number of potential foster and adoptive parents that have begun the preparation and training process. This increase has resulted in a significant opportunity for children available for adoption. That’s a big win for everyone! And it’s all because we can refer potential parents to the proper state contacts efficiently and quickly."
Chris Morrison
Executive Director
"Thank you for all of your expertise and valuable help. I am so grateful to have found DB Services."
Linda Findlay
Owner
"Thank you for our new database system. We transitioned from a carbon copy paper based system to a digital database. The software has saved us time and money. We used to archive all our jobs in cabinets, now we can look up a job in seconds from anywhere. The software allows us to easily email estimates to our customers in pdf format. In a year there was a return on investment just from eliminating the purchasing of our carbon forms."
Todd Cartmel
Owner
"The new system allows us to create and track jobs for customers along with inventory, something we had been doing with separate word and spreadsheet files. Because it’s now so intuitive, new staff members are able to begin using the database immediately without our usual training session and ‘cheat sheets’ for getting around within the file."
Tom Andrews
President