Options for Opening Hosted FileMaker Databases Quickly

I’m not usually a big fan of opening hosted FileMaker databases using ‘trigger’ files of any kind; but, the spinning beach ball I sometimes get when I don’t immediately interact with a just-launched copy of FileMaker Pro Advanced 11 ‘Quick’ Start screen has been driving me nuts. I needed a better way to get into my daily databases.

Traditionally a FileMaker developer would create a simple FileMaker file and set it up as follows:

• Create a new empty database (no tables or fields needed) [File > New Database…].
• Add an external data source which defines a path to a hosted FileMaker file [File > Manage > External Data Sources].
• Create a script that a) opens that FileMaker external data source or b) runs a script in it and then c) closes the trigger file [Scripts > Manage Scripts…]
• Set that script to fire when the trigger file opens [File > File Options…].

I’ve never really liked this approach – too many steps to set it up (or at least it seemed so to me) for such a basic/common need. Coincidentally, I’d also been curious about how much I could pare down the resulting .fpsl file that is created when I used the new FileMaker Pro 11 Snapshot Link feature [File > Save/Send Records As > Snapshot Link…]: If you have not made a Snapshot Link, or opened one with a text editor to take a peek at how it works, I suggest you take a look at it. Here’s a sample snapshot link file (with some spacing and carriage returns added to make it easier to read):

 <?xml version="1.0" encoding="UTF-8"?> <FPSL> 	<UIState> 		<UniversalPathList>fmnet:/127.0.0.1/FMServer_Sample</UniversalPathList> 		<Rows type="nativeIDList" rowCount="51" baseTableId="130">&#10;<![CDATA[1-51 ]]>&#10;</Rows> 		<Layout id="19"></Layout> 		<View type="form"></View> 		<SelectedRow type="nativeID" id="1"></SelectedRow> 		<StatusToolbar visible="True"></StatusToolbar> 		<Mode value="browseMode"></Mode> 	</UIState> </FPSL>

You’ll note most of it seems pretty clear, so I tried trimming it down using a text editor:

 <?xml version="1.0" encoding="UTF-8"?> <FPSL> 	<UIState> 		<UniversalPathList>fmnet:/127.0.0.1/FMServer_Sample</UniversalPathList> 		<Rows type="nativeIDList" rowCount="0" baseTableId="130"></Rows> 		<Layout id="19"></Layout> 		<View type="form"></View> 		<Mode value="browseMode"></Mode> 	</UIState> </FPSL>

Then I started looking for alternatives. My first stop was to take a closer look at a .inetloc file (OS X only). These files are usually created by dragging a URL from a browser’s address bar or a word processing document to the desktop, where the OS turns it into a .inetloc file. When you open a .inetloc file, Mac OS X consults its Launch Services database to figure out which application can handle the URL contained in the file, then it passes the URL to that application, e.g. FileMaker Pro. Here’s what a .inetloc file looks like ‘under the hood’:

 <dict> 	<key>URL</key> 	<string>fmp7://127.0.0.1/FMServer_Sample.fp7</string> </dict>

My next stop was to take a closer look at a .url file (available on OS X or Windows), which is created in a similar way, but which looks different ‘under the hood’:

 [InternetShortcut] URL=fmp7://127.0.0.1/FMServer_Sample.fp7 IDList= HotKey=0 IconIndex=1 [{000214A0-0000-0000-C000-000000000046}] Prop3=19,0

… and which behave differently, i.e. a when you double-click a .url file it invokes a web browser, which then in turn hands that call off directly to the proper application for handling them, i.e. in this case that’s FileMaker Pro. In short that’s two steps to get to your app, and if our browser is not launched already, it’s an additional delay. Otherwise, the differences boil down as follows:

• The altered .fpsl always ends with a found set of 0 records; whereas, the .inetloc or .url files will execute the startup script and show records, etc. – if any.
• The first time any of the files are used, if the target file is not already open, all follow the startup process to completion; but then, the .fpsl file applies the layout, found set, sort order, etc., in the same window (whereas normally it opens a new window).
• The new window behavior of .fpsl is neat; but, it can be a real bummer if the database is hosted. For example, if you already have your database open and the specific layout shown, and you use the .fpsl file a second time, the new window:
  • does not follow the startup script, which is expected behavior; because, another window already invoked it. However, it also …
  • seems to ignore the default behavior of a new window, which is to inherit the found set from the current window, i.e., I briefly got all records in the table, which can be undesirable, and which occurred before the .fpsl file applied any changes to the layout, found set, sort order, etc.
• The .inetloc and .url files can be used repeatedly and with impunity. If the target database is already open, it just brings it to the foreground.

My vote? Use a .inetloc file in OS X only environments, and a .url file for mixed OS X and Windows environments. Mark Richman is President, FileMaker Certified Developer, Filemaker Authorized Training at Skeleton Key. About Skeleton Key Skeleton Key is an accomplished team of technology consultants who solve business problems. We specialize in the rapid development of custom applications, integrating Macs and PCs in the professional workplace, and providing personalized training. Despite our end-to-end technical skills, we are consultant first and technologist second. We know that you don’t just need technology. You need to know that the technology you choose to deploy will provide the results you desire. Skeleton Key is a Platinum Level FileMaker Business Alliance company, an Authorized FileMaker Trainer, a member of the Apple Consultants Network and a Microsoft Registered Partner.