It is likely that you have multiple copies of the original form in the ODK
Briefcase storage area. Try downloading the data to a new ODK Briefcase
storage location, rather than reusing an existing location. Do you still
If you do still see duplicates, is the PARENT_KEY field the same for these
rows, or is it different. If it is different, this would indicate that you
have two different submissions contributing to the apparent duplicates.
Note that after pulling data from ODK Collect, the data remains on the ODK
Collect device, and you need to manually delete it via the Delete Saved
Forms screen. If you have entries with different PARENT_KEY values, it is
likely because you never deleted the earlier submissions.
Note that the instanceID does not prevent duplicate forms from co-existing
in ODK Briefcase. ODK Briefcase does not do the de-duplication processing
that ODK Aggregate does. De-duplication is currently handled in ODK
ODK Briefcase pulls data from data sources, and the last data source it
pulls from either "wins" (for ODK Aggregate) or "coexists" (for ODK
Collect). Once the data is pulled from ODK Collect, it is important that
you then go to the Delete Saved Forms screen and delete them from the
phone, otherwise, on the next pull, you will get a second copy of those
forms, plus an initial copy of any new form.
Additional inspection and comparison code would have to be added to enable
ODK Briefcase to decide whether two copies of a submission copied from ODK
Collect are identical. If two or more filled-in forms collide, they will
coexist in the Briefcase storage location as
You would need to decide whether these are actual duplicates or simply due
to two or more phones happening to pick the same collect-directory-name for
their different submissions. This is where the additional inspection and
comparision code would need to be written. In this case, since the
filled-in form reflects updated values, I would expect that this inspection
and comparison code would identify them as different and would still decide
to keep both.
On Fri, Aug 17, 2012 at 5:36 AM, Curtis Broderick <firstname.lastname@example.org wrote:
Anyone for triplicates? I am getting a little lost here, and am not sure
if my duplicates from briefcase are happening in the same context. I
created a form with a repeating group. I use that repeat group each time I
want to save an event"s data. For example, the form starts with the
person's name, etc, but the repeating group gets his/her blood pressure and
weight. I save the form with the person's name. A month later, I can open
that form -- because I named it with the person's name, jump to the
repeating group and add another event (blood pressure and weight). The
problem is, when I do a pull and export to csv, the first time it is OK,
records look great, but the second time I do a pull & export (in the
meantime I added more events to a person's form), I see duplicates (and
even triplicates and quadruplets) in both the main and child csv files. I
know that repeat groups were not designed as a 1-n DB child table, but I
would think I could use it for that (Imagine getting three samples per day
of something from 10 people over a period of 10 days) -- the repeat groups
would act as the sample event data capture. So what am I doing wrong to get
duplicates and triplicates?
Le lundi 14 mai 2012 19:52:57 UTC+2, OutSourceRox a écrit :
Thanks for the tip. Jon, I guess we should add that field into the forms
soon as possible, just as precaution to prevent a similar incident which
Ricky (upload over what was already uploaded).
On Mon, May 14, 2012 at 1:36 PM, Mitch S mitche...@gmail.com wrote:
Briefcase DOES NOT delete any data off your phone. It is up to you,
after using briefcase, to select the forms on the phone and delete them.
Additionally, Briefcase does not attempt to find only the finalized forms
on your phone -- it will grab everything. So you should first finalize the
forms on the phone; if that isn't possible, you can go into Briefcase's
directory tree and delete the incomplete submissions from there, if needed
(they will generally have the same directory name at this point).
As for duplicates, you should define an instanceID in your form
<bind nodeset="/nm/meta/instanceID" type="string"
readonly="true()" calculate="concat('uuid:', uuid())"/>
You can omit the orx: namespace prefix, but the above follows the
OpenRosa metadata standard ( https://bitbucket.org/**
javarosa/javarosa/wiki/**OpenRosaMetaDataSchemahttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema). Aggregate recognizes the
http://openrosa.org/xforms/ (orx) namespace or a blank (default)
namespace and looks for the first occurance of meta/instanceID in the form
and uses that value as the unique identifier for the submission. If a
filled-in form has a unique identifier, Aggregate can merge the multiple
uploads and prevent duplications.
On Mon, May 14, 2012 at 9:23 AM, Jon Parsons j.pa...@globalcanopy.orgwrote:
We have used briefcase in the field in Guyana, to get around internet
connection problems, as the phones just would not send data direct through
wifi and gave us all sorts of error and connection problems. BTW We only
had a 512kbs down and 256kbs up data rate through a satelite that was
giving us an actual 200kbs down and 50kbs up rate.
But I have two questions about briefcase and its use
- We have noticed that when briefcase pulls data from the phone, the
data still there in the send finalised form area, so if the phone is then
finally connects to good internet, these forms will be submitted and create
- Also when the data is collected together in briefcase and then sent
as a batch (we did 15 submissions) and it says sending 1 of 15 etc - if
this fails at 10 of 15 due to poor internet, if you re action the send
request it sends all the submissions again and then creates duplicates in
Is there any way to get around these problems or is there a way to
manage the duplicates better in appspot.
University of Washington
Play it forward and Have a good one!
"Like a camera I use the negative to develop..uDig"
"Success is the ability to go from one failure to another with no loss of
Roxroy K. Bollers
GIS and IT Consultant
Follow Us On
University of Washington