Download - MyWeb - Texas Tech University

The 2012 Season of the Chan Chich Archaeological Project
of the database would be copied to each
laptop (“CCAP Database 5-29-12 iPad 1,” for
example). By using this system, each version
of the database was preserved as a backup each
time the information was downloaded from the
field.
From Theory to Practice
Question: What’s the difference between the
Titanic and the CCAP FileMaker database
Answer: The Titanic was easier to sync.
FileMaker Pro and FileMaker Go: The
“Syncing” Problem
The problems with the database became
apparent on the first attempt to sync the iPads.
On the first day of field work, four iPads, each
loaded with a blank version of the FileMaker
Pro database were sent out into the field: two
to Kaxil Uinic and two to Chan Chich. Once
one of the project staff members entered a form
on a given iPad, a new version of the database
existed. When it came time to sync the four
iPads, four different versions of the database
were brought in from “the wild,” each full of
unique information sharing the same database
structure. As we learned, the process to combine
the databases was not really syncing, but
was rather importing into FileMaker Pro and
exporting back to FileMaker Go. True syncing
would merge the various databases together.
Syncing was what we planned to do; importing
and exporting were what we could do.
Problems immediately arose with higher-order
forms like the Site Summary and Operation
Definition forms. For example, because each
level of form required the next highest level to
be created first (i.e., you could not complete a
Suboperation Definition form until an Operation
Definition form had been first created), each
supervisor created a Site Summary form
followed by an Operation Definition form on
their respective iPads. This meant that there
were two Site Summary forms for Chan Chich
and two Operation Definition forms for Op
CC-10, for example. During importing, the
form on the second file of the two Chan Chich
field databases to be imported into the master
version on the MacBook Pro would trump the
first and overwrite it, simply by virtue of its
having imported last.
Once this problem was realized, a number of
steps were taken to facilitate the importing
process. First, the original master database,
which had included both Kaxil Uinic and
Chan Chich, was saved as two separate files,
one for each site. Second, each operation
director was instructed to only make changes
to high order forms and those that applied to
multiple suboperations on only one iPad. These
included the Site Summary form, the Operation
Definition form, the Sample form, and the
List of Datums form. Those forms would be
imported from the operation director’s iPad
and exported to both iPads at each site during
database updating. Third, each iPad was
assigned to specific suboperations so that the
Suboperation Definition forms and Lot forms
for each unit would only be modified on one of
the field iPads.
These steps eliminated most problems with
duplicate forms, but not all problems during
importing. FileMaker Pro’s import function
from one file to another is done one form at
a time. This meant that for each field form
(Suboperation Definition form, Lot form, etc.),
a separate import had to be done for each of the
four iPads. This proved to be a time-consuming
and unexpected task.
Another unexpected problem with the database
was that when Lot forms were imported the
rather critical information entered in the “Field
Collection” portal was not brought into the
master database (Figure 7.4). Because the
“Field Collection” information was used to
generate the Field-to-Lab Bag Check In form,
80