14 for 14: Reconnect with your Databases

Introductions first...

This is the first article written for Weetbicks by Craig Saunders - our Director and master chief (be nice in the comments section, he pays my wages! - Daniel)

Let's Stick Together

New in FileMaker 14 is the automatic “reconnect to server” feature which I particularly love.

Basically FileMaker reconnects you automatically if you’ve lost your connection to the server, such as when you close your laptop then open it up again some time or place later... With ‘reconnect’ FMP will carry on where you left off without the need to log in all over again.

FileMaker Go has always had this great feature but as of FM14 it’s now in the desktop products too, i.e. FileMaker Pro 14 and FileMaker Pro Advanced 14. And it works with Server 13 or 14 so it’s an instant win even if you’re still running a 13 server.

Reconnect might not sound like a major feature but it makes huge difference to performance over the internet and the resulting end user experience. Let me explain...

FileMaker is a Distributed Database

When you first connect to a solution the FileMaker Pro client downloads a large deal of information about the solution including the database schema (tables, fields and relationship graph) and layout and record information for the layout you first land on. Then as you browse records the data itself is also downloaded and ‘cached’ locally. Scripts, value lists, indexes and of course the layout information are also cached as you use the system.

You see this quite dramatically when you run a report: the first time, a moderate report might take a minute or two to run. Run it again and it can be almost instant, such is the magic of caching.

When you log out or disconnect, all that hard earned cache data is deleted—it’s a “temporary” working copy after all, right? But what if you could keep it...?

Essentially reconnect does just that–allows you to keep the cache. In other words if you don’t close the database at the end of day or when you unplug, then FileMaker keeps the cache and can carry on at a later time — i.e. when you have an internet connection again.

FileMaker’s distributed database technology handles the changes to... it could be a week or a month later when you reconnect, and FileMaker always knows which records, layouts etc, have changed and will update your cache as need be when you reconnect.

Bad Behaviour

In practice it’s not entirely “graceful” how this happens but it works fairly well and with a trick or two and some education for users it works like magic.

Here’s what happens: When the connection is lost FileMaker will try to alert the user—on a Mac, the dock icon bounces a couple of times and this horrific message will confront you:

(I can see why the good folks at FMI felt the need to explain what’s going on here but that is a lot of information for a user to wrap their head around. It’d be a lot better if the message was worded according to the user privileges—if you don’t have access to Layout editing etc then that detail isn’t needed so it could be kept very simple.)

Anyway the correct answer is “Reconnect” which basically means “Yeah, carry on, as you were.”

Actually if you just leave it alone the dialog will go away and it’ll reconnect by itself if it can or just keep trying quietly in the background ad nauseam.

In fact if you hit “Reconnect” and it can’t reconnect, the files will close giving you no further choice in the matter. Whereas, say you’re on a plane (with no internet), if you just leave FileMaker alone it will:

• display the wordy dialog
• try to connect and fail
• dismiss the dialog
• connect when you get the connection back

So the moral of the story is that you’re better just to wait and see what happens!

Too bad FM had to bother the user with the dialog in the first place—to my mind that should only be necessary if the user tries to actually use the database before reconnection is sorted. And perhaps it should just say “This database can’t be used until you’re connected to the internet again.”

Ideally the database should be “paused”, dimmed out or something, allowing you to use FileMaker for other things like working on any local databases.

In fact the ultimate answer is that FileMaker should never throw out the cache (unless specifically ‘asked’ to) so that even if you do close the database, when you re-open the same database the cache should be able to be used again. With the cache encrypted and inaccessible there’s no harm in keeping it around. Go lobby for this feature if you agree... :-)

Another Catch

The reconnect works great with a single file solution, however there’s a problem when you have multiple files or interface / data separation (e.g. where the initial interface or main file is the one you log in to, then other files are opened using the same credentials in the background).

The problem is that during reconnect those credentials are not passed on to the background files in certain circumstances and the user will be bothered by an authentication dialog:

Have I mentioned that I despise dialog boxes? A dialog is a slap in the face for the user, so general tip: Don’t Do Modal Dialogs!

Anyway there’s another great feature missing here which is the ability to store the credentials in the keychain. Compare the above dialog with the standard authentication dialog when opening a solution:

See the difference – there’s an option to store their user name and password in the keychain so that provided the user is logged in on the device, the solution will open and authenticate completely automatically.

I first noticed this with Go where the ability to store the user name and password creds in the keychain is a real boon (though it begs the question, what sort of security practices should we have around this?)

Certain Circumstances

During the writing of this article I figured out that this authentication issue doesn’t always happen in multi file solutions - only in “certain circumstances”...

In the end I nailed it down to the fmreauthenticate extended privilege, which exists for the purpose of dictating how long FileMaker Go can be switched out before requiring the user to re-authenticate.

Turns out in 14 fmreauthenticate also affects FMPro but not quite as you’d expect: it doesn’t dictate how long before you have to re-authenticate, rather it will force re-authentication if it’s not the same in all files. In other words:

All files in a multi-file solution must have the same fmreauthenticate privilege for any given privilege set.

However it doesn’t matter what value it actually has, so it could be fmreauthenticate0 or fmreauthenticate10 or whatever.

Go behaves a bit more as you’d expect—i.e. if you set a big fmreauthenticate number (which is the number of minutes since the app was used before requiring re-authentication, then users won’t need to re-authenticate provided they come back within that period.

The maximum number for fmreauthenticate is 10080, i.e. fmreauthenticate10080 which is 7 days. So anyone returning to the app after more than 7 days would have to manually enter their user name and password again.

Still Not Entirely Happy

So that’s the easy solution.

However I’m still not entirely happy: given that FileMaker has given users the means to store their credentials in the keychain for automatic log in, any file that is thus opened (whether directly or indirectly) should never ask for the user name and password even if it is a week or a more later since it was last used, and indeed the main file won’t but any background files will.

One option is to not allow the creds to be stored in the keychain for your solution. You can do that in the File Options settings:

Still not happy though—there are legitimate cases for allowing this so why disable it? A better answer seems to be that we’d need to provide an easy means for the user to store the user name and password for the other files in their keychain. This is going to be a slightly annoying step to have to do but it’s one-off and workable as long as there aren’t many other files (e.g. separation model solutions typically have only 2 or 3 files).

I haven’t worked out the best way to tackle that type of solution, but you basically you’d want to make automate the process so that users could elect to “Store Authentication Details”, and then be prompted for each of the files. To do that they have to be opened directly (as opposed to indirectly from a main file that has access to them).

I can think of 2 possible solutions for having this function built into the front end or main file:

1. At start up before any of the secondary files are referenced, use Open URL to directly open the secondary databases. You can’t use the standard Open File command because the file you’re on has the same credentials and an external reference to that file so passes on the credentials automatically.
2. Create a standalone “Authenticator” file which has no credentials in it: you can then use the standard Open File command and will get the full authentication dialog with “Store in Keychain” option. There’re a number of ways of instigating the process but the key thing is that the actual solution files must be closed for the Authentication process to work.

One More Thing

For all of this to work we need to encourage (or prevent even) users from closing the solution: there are a number of ways of doing that:

• Tell them not to: e.g. “A kitten dies if you close this database.”
• Or you could just use the window controls to give the user a window with the close control disabled:

• Daniel suggests a variant on this which provides for "a per user approach" by putting twink or tape on the individuals screen where the close control appears.

Either way this approach could be a confusing and frustrating—you’re taking away an expected behaviour so another alternative would be: 

• Intercept the script trigger for “Last Window Close” and do something like this which lets the user decide whether to actually close or just hide the solution

Mind you I did say that dialogs are evil, so you could just Hide the solution by default and give users a more explicit “Close Solution” button or control within the solution itself: if your users are the kind who hit the close box just get the solution out of the way then this is the probably the best answer.

(I tried the dialog approach on one of our own databases and found that it works really well especially with Hibernate as the default in the dialog so 9 times out of 10 you just hit return to accept that action.)

Official Information

Finally, here’s what FileMaker have to say about this feature:

http://help.filemaker.com/app/answers/detail/a_id/14232

(Note that although the automatic reconnect attempt gets longer, it will attempt to reconnect instantly if the user “opens” the database again or clicks onto it at all.)

All Good then?

I know this all sounds fiddly and is a distraction from your main focus of building features and functionality into your solutions, but if the solution is being used over the internet then get this process sorted your users will love it.