The FMTouch software served us well during the 2010 season. In the middle of the season FileMaker came out with their own software: FileMaker Go. FileMaker Go does not rely on the DDR to create the database layout as does FMTouch. Instead the original FileMaker database can be copied to the iPad using the file transfer feature in iTunes. FileMaker Go then opens up the database with fewer limitations than FMTouch. Most script steps, calculations, and layouts just work. FileMaker Go will also let you open a database over a network,  so that multiple people can edit the database at the same time. The JMP project, mentioned in the previous post, used FileMaker Go.

Since our iPads work offline in the trench, we would need to have a copy of the database on all iPads. With three trenches open and all of them running their own local databases, and the ‘live’ hosted database being edited nearby we would have four copies of the same database. This leads us to the downside of FileMaker Go: no automatic syncing. That is the strong suit of FMTouch and one that will be missed. Instead I will have to alter our database to allow audit trails where we track changes to the database on each device (something I have been meaning to do anyway), and create my own scripts for syncing the data to avoid overwriting new data with old.

The audit trail should be fairly easy to do. Essentially I need to create a new table to hold the old and new data and use script triggers in the layouts to force new records to be created in the audit table.

The syncing is a different matter. I have been following how some people handle syncing and how some have had problems doing so. For instance  I use Dropbox heavily and I never have to worry about syncing issues. But my iDisk seems to have issues regularly. And the folks at Cultured Code, the developers of Things (GTD task management software) seem to be taking their own time waxing philosophically about how sync should work. I have also been reading about Zotero’s syncing issues. So I get it, syncing is hard but can be done and I will work on getting something in place soon so I have time to test it before we make our final decision about databases this year.

One of the problems I recently noticed is that the iPad does not sync with a time server. Last week I noticed that my iPad was over 5 minutes off and right now it is 63 seconds slow (thanks Emerald Time!). This means that I have to adjust the sync script to allow for some minor time discrepancies when recognizing the creation and modification times of a record.

Once I get these issues worked out, I will post a new version of the database.

The iPad version of the database looks vastly different from the desktop. We stripped all but the essential fields from the database in order to speed it up and make the syncing go faster. The elements here are all designed for the iPad, with larger text fields and elements such as radio buttons and checkboxes. We also made use of drop-down menus for dates and a few other fields.

The list view of SUs lets you browse through the list, but it isn’t a real list view. In FileMaker terms, it is a portal, and doesn’t sort properly (for instance SU 50010 is in the database but doesn’t show up in this list). We found a work-around by viewing the SU table in a table view (see below). The scripting engine in FMTouch isn’t as robust as the FileMaker itself, and while the FMTouch database knows which SUs are fills and which ones are wallSUs, it can’t go to a layout based on that data, so there are buttons for both Wall and Fill and you have to tap the right one to see the right screen. Read the rest of this entry »