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.
Paperless Archaeology 
John, I’m wondering why you work offline while in the trench rather than access a shared database over a wifi network – is the radio reception not up to it?
Con,
Radio and electricity are the issues. Take a look at the plan on the main PARP:PS webpage as well as the photo of the insula on this page. Our work tables are actually inside of the porta stabia gate itself to give us some shelter. That is where the database lives. We have a locally generated wi-fi network hosted from one of the laptops so several computers can work inside the gate with just battery power, but it can’t reach the trenches.
The only way we can get wifi to the trenches would be to put a base station and possibly an antenna on top of the gate pointing to the trenches. But we don’t have power all the time and some days don’t have it at all. So we can’t run the external base station. Even if we could, the standing architecture is so high, it would not reach the areas we are working in (stone is death for wi-fi signals). Therefore we look for offline solutions only.