Generating a Unique ID for a Form Submission

We are running into a problem where if we send in a submission that
has several photos, the submission is getting broken up into several
entries in the form's _CORE table (_IS_COMPLETE = 0).

I do not understand why ODK does this. The issue is that when this
happens, there is no way to group together the _CORE rows to know
which data was submitted with the same form instance.

The best option we have come up with is to try and match the data
fields in the _CORE table, but this will not guarantee that we are
putting the correct pieces of data together - if one user submits
multiple form instances that contain identical data in the _CORE table
(and different data in the other tables), then how do we know where
the separation is?

My thought was to create a unique ID that would be a field in the
_CORE table and would be generated each time the user creates a new
instance of the form. The unique ID could be the username
+current_timestamp, or anything else that would be unique.

Any ideas / comment would be greatly appreciated.

If the transmission to the server will be greater than 10MB, it is split
across multiple submissions. This is to bound the size of the Virtual
Machine running on the server.

To avoid this problem , specify an instanceID in the form, as defined here:
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema For
ODK Aggregate, you don't need to specify the namespace, just have a

group in your form.

With ODK Collect 1.1.7 and later, the bind for this element that replicates
the instanceID that would otherwise be generated by Aggregate would be:

You can construct your own instanceID expressions. However, you should
avoid symbols and punctuation other than colons and dashes since the
parsing logic within Aggregate is likely fragile if you go wild with
punctuation (and that is used later on when retrieving images, repeat
groups, etc.). If you do construct your own values, they must be less than
255 characters long and must be unique across all devices and submissions.

Mitch

··· On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated <feltpadinc@gmail.com wrote:

We are running into a problem where if we send in a submission that
has several photos, the submission is getting broken up into several
entries in the form's _CORE table (_IS_COMPLETE = 0).

I do not understand why ODK does this. The issue is that when this
happens, there is no way to group together the _CORE rows to know
which data was submitted with the same form instance.

The best option we have come up with is to try and match the data
fields in the _CORE table, but this will not guarantee that we are
putting the correct pieces of data together - if one user submits
multiple form instances that contain identical data in the _CORE table
(and different data in the other tables), then how do we know where
the separation is?

My thought was to create a unique ID that would be a field in the
_CORE table and would be generated each time the user creates a new
instance of the form. The unique ID could be the username
+current_timestamp, or anything else that would be unique.

Any ideas / comment would be greatly appreciated.

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Thank you for the tips about generating the Unique ID. Does this somehow
stop the data from appearing as multiple rows in the form's _CORE table? I
was expecting to have to join data based on the Unique ID, but none of my
entries have been broken into multiple rows since I implemented the Unique
ID - maybe just coincidence at this point, but I'm pretty sure my
submissions have exceeded the 10 MB limit.

Mitchell,
I guess I have a similar problem, but specifically with the repeating
groups (rosters): Is there a way that the looped data should be
joined to the parent data rather than having them coming as separate
with the generated parent keys? If this is not possible, then, how
well could I merge the two different data instances (parent and roster
tables); I am using stata 11.

Humphreys.

··· On Mar 29, 11:00 am, Mitch S wrote: > If the transmission to the server will be greater than 10MB, it is split > across multiple submissions. This is to bound the size of the Virtual > Machine running on the server. > > To avoid this problem , specify an instanceID in the form, as defined here:https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema For > ODK Aggregate, you don't need to specify the namespace, just have a > group in your form. > > With ODK Collect 1.1.7 and later, the bind for this element that replicates > the instanceID that would otherwise be generated by Aggregate would be: > > calculate="concat('uuid:', uuid())"/> > > You can construct your own instanceID expressions. However, you should > avoid symbols and punctuation other than colons and dashes since the > parsing logic within Aggregate is likely fragile if you go wild with > punctuation (and that is used later on when retrieving images, repeat > groups, etc.). If you do construct your own values, they must be less than > 255 characters long and must be unique across all devices and submissions. > > Mitch > > On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated > We are running into a problem where if we send in a submission that > > has several photos, the submission is getting broken up into several > > entries in the form's _CORE table (_IS_COMPLETE = 0). > > > I do not understand why ODK does this. The issue is that when this > > happens, there is no way to group together the _CORE rows to know > > which data was submitted with the same form instance. > > > The best option we have come up with is to try and match the data > > fields in the _CORE table, but this will not guarantee that we are > > putting the correct pieces of data together - if one user submits > > multiple form instances that contain identical data in the _CORE table > > (and different data in the other tables), then how do we know where > > the separation is? > > > My thought was to create a unique ID that would be a field in the > > _CORE table and would be generated each time the user creates a new > > instance of the form. The unique ID could be the username > > +current_timestamp, or anything else that would be unique. > > > Any ideas / comment would be greatly appreciated. > > > -- > > Post: opendatakit@googlegroups.com > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > > Options:http://groups.google.com/group/opendatakit?hl=en > > -- > Mitch Sundt > Software Engineer > University of Washington > mitchellsu...@gmail.com

Yes, by specifying a unique ID in the form, you enable Aggregate to
identify and merge the values across the multiple transmissions, yielding
only one composite record of the results in Aggregate -- all the clerical
work is handled by the program, rather than by you.

Mitch

··· On Mon, Apr 2, 2012 at 9:17 AM, Feltpad Incorporated wrote:

Thank you for the tips about generating the Unique ID. Does this somehow
stop the data from appearing as multiple rows in the form's _CORE table? I
was expecting to have to join data based on the Unique ID, but none of my
entries have been broken into multiple rows since I implemented the Unique
ID - maybe just coincidence at this point, but I'm pretty sure my
submissions have exceeded the 10 MB limit.

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Hi Mitch,
Just to clarify, this solution also works in preventing duplicate entries
when submittingf orms via ODK Collect/KoboCollect? So I just paste this the
following text in the beginning of any form and it will prevent duplicates
entries in Aggregate?


Will this field also be part of the csv output file? I'm keen on
implementing this solution for Phase 2 -- hoping that duplicates will be a
thing of the past. Thanks a million for the tip!

~DataMax

··· ===============

On Thursday, March 29, 2012 9:00:22 PM UTC+3, Mitch wrote:

If the transmission to the server will be greater than 10MB, it is split
across multiple submissions. This is to bound the size of the Virtual
Machine running on the server.

To avoid this problem , specify an instanceID in the form, as defined
here: https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema
For ODK Aggregate, you don't need to specify the namespace, just have a

group in your form.

With ODK Collect 1.1.7 and later, the bind for this element that
replicates the instanceID that would otherwise be generated by Aggregate
would be:

You can construct your own instanceID expressions. However, you should
avoid symbols and punctuation other than colons and dashes since the
parsing logic within Aggregate is likely fragile if you go wild with
punctuation (and that is used later on when retrieving images, repeat
groups, etc.). If you do construct your own values, they must be less than
255 characters long and must be unique across all devices and submissions.

Mitch

On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated <feltp...@gmail.com<javascript:> wrote:

We are running into a problem where if we send in a submission that
has several photos, the submission is getting broken up into several
entries in the form's _CORE table (_IS_COMPLETE = 0).

I do not understand why ODK does this. The issue is that when this
happens, there is no way to group together the _CORE rows to know
which data was submitted with the same form instance.

The best option we have come up with is to try and match the data
fields in the _CORE table, but this will not guarantee that we are
putting the correct pieces of data together - if one user submits
multiple form instances that contain identical data in the _CORE table
(and different data in the other tables), then how do we know where
the separation is?

My thought was to create a unique ID that would be a field in the
_CORE table and would be generated each time the user creates a new
instance of the form. The unique ID could be the username
+current_timestamp, or anything else that would be unique.

Any ideas / comment would be greatly appreciated.

--
Post: opend...@googlegroups.com <javascript:>
Unsubscribe: opendatakit...@googlegroups.com <javascript:>
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com <javascript:>

That's a different issue.

If you have a form with a repeat group, you can use ODK Briefcase to
download the submissions to your local machine then use ODK Briefcase
(rather than ODK Aggregate) to Export to CSV that form data. This will
produce a CSV for the overall form, and a CSV for each repeat group in the
form definition. There are columns on the far right of the rows in these
files that enable you to pair up the data across these tables.

Mitch

··· On Fri, Mar 30, 2012 at 3:53 AM, Humphreys Kabota < humphreys.kabota@investinknowledge.org> wrote:

Mitchell,
I guess I have a similar problem, but specifically with the repeating
groups (rosters): Is there a way that the looped data should be
joined to the parent data rather than having them coming as separate
with the generated parent keys? If this is not possible, then, how
well could I merge the two different data instances (parent and roster
tables); I am using stata 11.

Humphreys.

On Mar 29, 11:00 am, Mitch S mitchellsu...@gmail.com wrote:

If the transmission to the server will be greater than 10MB, it is split
across multiple submissions. This is to bound the size of the Virtual
Machine running on the server.

To avoid this problem , specify an instanceID in the form, as defined
here:https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema
For
ODK Aggregate, you don't need to specify the namespace, just have a

group in your form.

With ODK Collect 1.1.7 and later, the bind for this element that
replicates
the instanceID that would otherwise be generated by Aggregate would be:

You can construct your own instanceID expressions. However, you should
avoid symbols and punctuation other than colons and dashes since the
parsing logic within Aggregate is likely fragile if you go wild with
punctuation (and that is used later on when retrieving images, repeat
groups, etc.). If you do construct your own values, they must be less
than
255 characters long and must be unique across all devices and
submissions.

Mitch

On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated < feltpad...@gmail.com wrote:

We are running into a problem where if we send in a submission that
has several photos, the submission is getting broken up into several
entries in the form's _CORE table (_IS_COMPLETE = 0).

I do not understand why ODK does this. The issue is that when this
happens, there is no way to group together the _CORE rows to know
which data was submitted with the same form instance.

The best option we have come up with is to try and match the data
fields in the _CORE table, but this will not guarantee that we are
putting the correct pieces of data together - if one user submits
multiple form instances that contain identical data in the _CORE table
(and different data in the other tables), then how do we know where
the separation is?

My thought was to create a unique ID that would be a field in the
_CORE table and would be generated each time the user creates a new
instance of the form. The unique ID could be the username
+current_timestamp, or anything else that would be unique.

Any ideas / comment would be greatly appreciated.

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options:http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsu...@gmail.com

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Yes, this would appear in the CSV.

··· On Thu, Aug 16, 2012 at 4:06 PM, DataMax wrote:

Hi Mitch,
Just to clarify, this solution also works in preventing duplicate entries
when submittingf orms via ODK Collect/KoboCollect? So I just paste this the
following text in the beginning of any form and it will prevent duplicates
entries in Aggregate?


Will this field also be part of the csv output file? I'm keen on
implementing this solution for Phase 2 -- hoping that duplicates will be a
thing of the past. Thanks a million for the tip!

~DataMax

On Thursday, March 29, 2012 9:00:22 PM UTC+3, Mitch wrote:

If the transmission to the server will be greater than 10MB, it is split
across multiple submissions. This is to bound the size of the Virtual
Machine running on the server.

To avoid this problem , specify an instanceID in the form, as defined
here: https://bitbucket.org/javarosa/javarosa/wiki/
OpenRosaMetaDataSchemahttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema
For ODK Aggregate, you don't need to specify the namespace, just have a

group in your form.

With ODK Collect 1.1.7 and later, the bind for this element that
replicates the instanceID that would otherwise be generated by Aggregate
would be:

You can construct your own instanceID expressions. However, you should
avoid symbols and punctuation other than colons and dashes since the
parsing logic within Aggregate is likely fragile if you go wild with
punctuation (and that is used later on when retrieving images, repeat
groups, etc.). If you do construct your own values, they must be less than
255 characters long and must be unique across all devices and submissions.

Mitch

On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated < feltp...@gmail.com> wrote:

We are running into a problem where if we send in a submission that
has several photos, the submission is getting broken up into several
entries in the form's _CORE table (_IS_COMPLETE = 0).

I do not understand why ODK does this. The issue is that when this
happens, there is no way to group together the _CORE rows to know
which data was submitted with the same form instance.

The best option we have come up with is to try and match the data
fields in the _CORE table, but this will not guarantee that we are
putting the correct pieces of data together - if one user submits
multiple form instances that contain identical data in the _CORE table
(and different data in the other tables), then how do we know where
the separation is?

My thought was to create a unique ID that would be a field in the
_CORE table and would be generated each time the user creates a new
instance of the form. The unique ID could be the username
+current_timestamp, or anything else that would be unique.

Any ideas / comment would be greatly appreciated.

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.com
Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Hi Mitch (or anyone else with an answer),

Is there a way to link each form submitted with a personalized unique ID?

For example, we are surveying multiple households with multiple "repeat
groups." Each household is assigned a unique 7-digit ID at the outset of
the survey-- this is entered as an answer to a survey question. This ID is
the same for all members of the household. When we export mutiple completed
surveys to csv files using ODK Briefcase, the only way to tie each "row"
across multiple CSVs to a given household is to compare the KEY or
PARENT_KEY column in each CSV file.

Is there a way we could instead or in addition have the 7-digit unique ID
be the unique identifier that ties all rows or all individual answers of a
given survey together?

Thanks,
Sam

··· On Friday, March 30, 2012 5:54:16 PM UTC, Mitch wrote: > > That's a different issue. > > If you have a form with a repeat group, you can use ODK Briefcase to > download the submissions to your local machine then use ODK Briefcase > (rather than ODK Aggregate) to Export to CSV that form data. This will > produce a CSV for the overall form, and a CSV for each repeat group in the > form definition. There are columns on the far right of the rows in these > files that enable you to pair up the data across these tables. > > Mitch > > On Fri, Mar 30, 2012 at 3:53 AM, Humphreys Kabota < humphrey...@investinknowledge.org > wrote: > >> Mitchell, >> I guess I have a similar problem, but specifically with the repeating >> groups (rosters): Is there a way that the looped data should be >> joined to the parent data rather than having them coming as separate >> with the generated parent keys? If this is not possible, then, how >> well could I merge the two different data instances (parent and roster >> tables); I am using stata 11. >> >> Humphreys. >> >> On Mar 29, 11:00 am, Mitch S wrote: >> > If the transmission to the server will be greater than 10MB, it is split >> > across multiple submissions. This is to bound the size of the Virtual >> > Machine running on the server. >> > >> > To avoid this problem , specify an instanceID in the form, as defined >> here:https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema >> For >> > ODK Aggregate, you don't need to specify the namespace, just have a >> > group in your form. >> > >> > With ODK Collect 1.1.7 and later, the bind for this element that >> replicates >> > the instanceID that would otherwise be generated by Aggregate would be: >> > >> > > > calculate="concat('uuid:', uuid())"/> >> > >> > You can construct your own instanceID expressions. However, you should >> > avoid symbols and punctuation other than colons and dashes since the >> > parsing logic within Aggregate is likely fragile if you go wild with >> > punctuation (and that is used later on when retrieving images, repeat >> > groups, etc.). If you do construct your own values, they must be less >> than >> > 255 characters long and must be unique across all devices and >> submissions. >> > >> > Mitch >> > >> > On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated < feltpad...@gmail.com wrote: >> > > We are running into a problem where if we send in a submission that >> > > has several photos, the submission is getting broken up into several >> > > entries in the form's _CORE table (_IS_COMPLETE = 0). >> > >> > > I do not understand why ODK does this. The issue is that when this >> > > happens, there is no way to group together the _CORE rows to know >> > > which data was submitted with the same form instance. >> > >> > > The best option we have come up with is to try and match the data >> > > fields in the _CORE table, but this will not guarantee that we are >> > > putting the correct pieces of data together - if one user submits >> > > multiple form instances that contain identical data in the _CORE table >> > > (and different data in the other tables), then how do we know where >> > > the separation is? >> > >> > > My thought was to create a unique ID that would be a field in the >> > > _CORE table and would be generated each time the user creates a new >> > > instance of the form. The unique ID could be the username >> > > +current_timestamp, or anything else that would be unique. >> > >> > > Any ideas / comment would be greatly appreciated. >> > >> > > -- >> > > Post: opend...@googlegroups.com >> > > Unsubscribe: opendatakit...@googlegroups.com >> > > Options:http://groups.google.com/group/opendatakit?hl=en >> > >> > -- >> > Mitch Sundt >> > Software Engineer >> > University of Washington >> > mitchellsu...@gmail.com >> >> -- >> Post: opend...@googlegroups.com >> Unsubscribe: opendatakit...@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >

Hi Sam,

I had the same issue, and Yaw helped me out. You can insert the ID through
calculation, where the calculation = the name of the unique ID question. If
you're creating forms as xls and converting to xlm (the only way I know how
to do it) then you'd:

make sure you have a column called 'calculation'
after your begin repeat, enter a line with type: calculate
read_only: yes
calculation: ${name of ID variable}

Works like a charm.

-Victoria

··· On Monday, 28 January 2013 11:58:10 UTC, Sam wrote: > > Hi Mitch (or anyone else with an answer), > > Is there a way to link each form submitted with a personalized unique ID? > > For example, we are surveying multiple households with multiple "repeat > groups." Each household is assigned a unique 7-digit ID at the outset of > the survey-- this is entered as an answer to a survey question. This ID is > the same for all members of the household. When we export mutiple completed > surveys to csv files using ODK Briefcase, the only way to tie each "row" > across multiple CSVs to a given household is to compare the KEY or > PARENT_KEY column in each CSV file. > > Is there a way we could instead or in addition have the 7-digit unique ID > be the unique identifier that ties all rows or all individual answers of a > given survey together? > > Thanks, > Sam > > On Friday, March 30, 2012 5:54:16 PM UTC, Mitch wrote: >> >> That's a different issue. >> >> If you have a form with a repeat group, you can use ODK Briefcase to >> download the submissions to your local machine then use ODK Briefcase >> (rather than ODK Aggregate) to Export to CSV that form data. This will >> produce a CSV for the overall form, and a CSV for each repeat group in the >> form definition. There are columns on the far right of the rows in these >> files that enable you to pair up the data across these tables. >> >> Mitch >> >> On Fri, Mar 30, 2012 at 3:53 AM, Humphreys Kabota < humphrey...@investinknowledge.org> wrote: >> >>> Mitchell, >>> I guess I have a similar problem, but specifically with the repeating >>> groups (rosters): Is there a way that the looped data should be >>> joined to the parent data rather than having them coming as separate >>> with the generated parent keys? If this is not possible, then, how >>> well could I merge the two different data instances (parent and roster >>> tables); I am using stata 11. >>> >>> Humphreys. >>> >>> On Mar 29, 11:00 am, Mitch S wrote: >>> > If the transmission to the server will be greater than 10MB, it is >>> split >>> > across multiple submissions. This is to bound the size of the Virtual >>> > Machine running on the server. >>> > >>> > To avoid this problem , specify an instanceID in the form, as defined >>> here:https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema >>> For >>> > ODK Aggregate, you don't need to specify the namespace, just have a >>> > group in your form. >>> > >>> > With ODK Collect 1.1.7 and later, the bind for this element that >>> replicates >>> > the instanceID that would otherwise be generated by Aggregate would be: >>> > >>> > >> > calculate="concat('uuid:', uuid())"/> >>> > >>> > You can construct your own instanceID expressions. However, you should >>> > avoid symbols and punctuation other than colons and dashes since the >>> > parsing logic within Aggregate is likely fragile if you go wild with >>> > punctuation (and that is used later on when retrieving images, repeat >>> > groups, etc.). If you do construct your own values, they must be less >>> than >>> > 255 characters long and must be unique across all devices and >>> submissions. >>> > >>> > Mitch >>> > >>> > On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated < feltpad...@gmail.com wrote: >>> > > We are running into a problem where if we send in a submission that >>> > > has several photos, the submission is getting broken up into several >>> > > entries in the form's _CORE table (_IS_COMPLETE = 0). >>> > >>> > > I do not understand why ODK does this. The issue is that when this >>> > > happens, there is no way to group together the _CORE rows to know >>> > > which data was submitted with the same form instance. >>> > >>> > > The best option we have come up with is to try and match the data >>> > > fields in the _CORE table, but this will not guarantee that we are >>> > > putting the correct pieces of data together - if one user submits >>> > > multiple form instances that contain identical data in the _CORE >>> table >>> > > (and different data in the other tables), then how do we know where >>> > > the separation is? >>> > >>> > > My thought was to create a unique ID that would be a field in the >>> > > _CORE table and would be generated each time the user creates a new >>> > > instance of the form. The unique ID could be the username >>> > > +current_timestamp, or anything else that would be unique. >>> > >>> > > Any ideas / comment would be greatly appreciated. >>> > >>> > > -- >>> > > Post: opend...@googlegroups.com >>> > > Unsubscribe: opendatakit...@googlegroups.com >>> > > Options:http://groups.google.com/group/opendatakit?hl=en >>> > >>> > -- >>> > Mitch Sundt >>> > Software Engineer >>> > University of Washington >>> > mitchellsu...@gmail.com >>> >>> -- >>> Post: opend...@googlegroups.com >>> Unsubscribe: opendatakit...@googlegroups.com >>> Options: http://groups.google.com/group/opendatakit?hl=en >>> >> >> >> >> -- >> Mitch Sundt >> Software Engineer >> University of Washington >> mitche...@gmail.com >> >

This is a great hack! Thanks for sharing

··· On Jan 28, 2013 6:01 PM, "Victoria Trinies" wrote:

Hi Sam,

I had the same issue, and Yaw helped me out. You can insert the ID through
calculation, where the calculation = the name of the unique ID question. If
you're creating forms as xls and converting to xlm (the only way I know how
to do it) then you'd:

make sure you have a column called 'calculation'
after your begin repeat, enter a line with type: calculate
read_only: yes
calculation: ${name of ID variable}

Works like a charm.

-Victoria

On Monday, 28 January 2013 11:58:10 UTC, Sam wrote:

Hi Mitch (or anyone else with an answer),

Is there a way to link each form submitted with a personalized unique ID?

For example, we are surveying multiple households with multiple "repeat
groups." Each household is assigned a unique 7-digit ID at the outset of
the survey-- this is entered as an answer to a survey question. This ID is
the same for all members of the household. When we export mutiple completed
surveys to csv files using ODK Briefcase, the only way to tie each "row"
across multiple CSVs to a given household is to compare the KEY or
PARENT_KEY column in each CSV file.

Is there a way we could instead or in addition have the 7-digit unique ID
be the unique identifier that ties all rows or all individual answers of a
given survey together?

Thanks,
Sam

On Friday, March 30, 2012 5:54:16 PM UTC, Mitch wrote:

That's a different issue.

If you have a form with a repeat group, you can use ODK Briefcase to
download the submissions to your local machine then use ODK Briefcase
(rather than ODK Aggregate) to Export to CSV that form data. This will
produce a CSV for the overall form, and a CSV for each repeat group in the
form definition. There are columns on the far right of the rows in these
files that enable you to pair up the data across these tables.

Mitch

On Fri, Mar 30, 2012 at 3:53 AM, Humphreys Kabota <humphrey...@** investinknowledge.org> wrote:

Mitchell,
I guess I have a similar problem, but specifically with the repeating
groups (rosters): Is there a way that the looped data should be
joined to the parent data rather than having them coming as separate
with the generated parent keys? If this is not possible, then, how
well could I merge the two different data instances (parent and roster
tables); I am using stata 11.

Humphreys.

On Mar 29, 11:00 am, Mitch S mitchellsu...@gmail.com wrote:

If the transmission to the server will be greater than 10MB, it is
split
across multiple submissions. This is to bound the size of the Virtual
Machine running on the server.

To avoid this problem , specify an instanceID in the form, as defined
here:https://bitbucket.org/javarosa/javarosa/wiki/
OpenRosaMetaDataSchemahttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema
For
ODK Aggregate, you don't need to specify the namespace, just have a

group in your form.

With ODK Collect 1.1.7 and later, the bind for this element that
replicates
the instanceID that would otherwise be generated by Aggregate would
be:

You can construct your own instanceID expressions. However, you should
avoid symbols and punctuation other than colons and dashes since the
parsing logic within Aggregate is likely fragile if you go wild with
punctuation (and that is used later on when retrieving images, repeat
groups, etc.). If you do construct your own values, they must be
less than
255 characters long and must be unique across all devices and
submissions.

Mitch

On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated < feltpad...@gmail.com wrote:

We are running into a problem where if we send in a submission that
has several photos, the submission is getting broken up into several
entries in the form's _CORE table (_IS_COMPLETE = 0).

I do not understand why ODK does this. The issue is that when this
happens, there is no way to group together the _CORE rows to know
which data was submitted with the same form instance.

The best option we have come up with is to try and match the data
fields in the _CORE table, but this will not guarantee that we are
putting the correct pieces of data together - if one user submits
multiple form instances that contain identical data in the _CORE
table

(and different data in the other tables), then how do we know where
the separation is?

My thought was to create a unique ID that would be a field in the
_CORE table and would be generated each time the user creates a new
instance of the form. The unique ID could be the username
+current_timestamp, or anything else that would be unique.

Any ideas / comment would be greatly appreciated.

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.**com
Options:http://groups.google.**com/group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsu...@gmail.com

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.**com
Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

Excellent! Thanks, Victoria

··· On Monday, January 28, 2013 12:31:54 PM UTC, Victoria Trinies wrote: > > Hi Sam, > > I had the same issue, and Yaw helped me out. You can insert the ID through > calculation, where the calculation = the name of the unique ID question. If > you're creating forms as xls and converting to xlm (the only way I know how > to do it) then you'd: > > make sure you have a column called 'calculation' > after your begin repeat, enter a line with type: calculate > read_only: yes > calculation: ${name of ID variable} > > Works like a charm. > > -Victoria > > On Monday, 28 January 2013 11:58:10 UTC, Sam wrote: >> >> Hi Mitch (or anyone else with an answer), >> >> Is there a way to link each form submitted with a personalized unique ID? >> >> >> For example, we are surveying multiple households with multiple "repeat >> groups." Each household is assigned a unique 7-digit ID at the outset of >> the survey-- this is entered as an answer to a survey question. This ID is >> the same for all members of the household. When we export mutiple completed >> surveys to csv files using ODK Briefcase, the only way to tie each "row" >> across multiple CSVs to a given household is to compare the KEY or >> PARENT_KEY column in each CSV file. >> >> Is there a way we could instead or in addition have the 7-digit unique ID >> be the unique identifier that ties all rows or all individual answers of a >> given survey together? >> >> Thanks, >> Sam >> >> On Friday, March 30, 2012 5:54:16 PM UTC, Mitch wrote: >>> >>> That's a different issue. >>> >>> If you have a form with a repeat group, you can use ODK Briefcase to >>> download the submissions to your local machine then use ODK Briefcase >>> (rather than ODK Aggregate) to Export to CSV that form data. This will >>> produce a CSV for the overall form, and a CSV for each repeat group in the >>> form definition. There are columns on the far right of the rows in these >>> files that enable you to pair up the data across these tables. >>> >>> Mitch >>> >>> On Fri, Mar 30, 2012 at 3:53 AM, Humphreys Kabota < humphrey...@investinknowledge.org> wrote: >>> >>>> Mitchell, >>>> I guess I have a similar problem, but specifically with the repeating >>>> groups (rosters): Is there a way that the looped data should be >>>> joined to the parent data rather than having them coming as separate >>>> with the generated parent keys? If this is not possible, then, how >>>> well could I merge the two different data instances (parent and roster >>>> tables); I am using stata 11. >>>> >>>> Humphreys. >>>> >>>> On Mar 29, 11:00 am, Mitch S wrote: >>>> > If the transmission to the server will be greater than 10MB, it is >>>> split >>>> > across multiple submissions. This is to bound the size of the Virtual >>>> > Machine running on the server. >>>> > >>>> > To avoid this problem , specify an instanceID in the form, as defined >>>> here: >>>> https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema For >>>> > ODK Aggregate, you don't need to specify the namespace, just have a >>>> > group in your form. >>>> > >>>> > With ODK Collect 1.1.7 and later, the bind for this element that >>>> replicates >>>> > the instanceID that would otherwise be generated by Aggregate would >>>> be: >>>> > >>>> > >>> > calculate="concat('uuid:', uuid())"/> >>>> > >>>> > You can construct your own instanceID expressions. However, you should >>>> > avoid symbols and punctuation other than colons and dashes since the >>>> > parsing logic within Aggregate is likely fragile if you go wild with >>>> > punctuation (and that is used later on when retrieving images, repeat >>>> > groups, etc.). If you do construct your own values, they must be >>>> less than >>>> > 255 characters long and must be unique across all devices and >>>> submissions. >>>> > >>>> > Mitch >>>> > >>>> > On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated < feltpad...@gmail.com wrote: >>>> > > We are running into a problem where if we send in a submission that >>>> > > has several photos, the submission is getting broken up into several >>>> > > entries in the form's _CORE table (_IS_COMPLETE = 0). >>>> > >>>> > > I do not understand why ODK does this. The issue is that when this >>>> > > happens, there is no way to group together the _CORE rows to know >>>> > > which data was submitted with the same form instance. >>>> > >>>> > > The best option we have come up with is to try and match the data >>>> > > fields in the _CORE table, but this will not guarantee that we are >>>> > > putting the correct pieces of data together - if one user submits >>>> > > multiple form instances that contain identical data in the _CORE >>>> table >>>> > > (and different data in the other tables), then how do we know where >>>> > > the separation is? >>>> > >>>> > > My thought was to create a unique ID that would be a field in the >>>> > > _CORE table and would be generated each time the user creates a new >>>> > > instance of the form. The unique ID could be the username >>>> > > +current_timestamp, or anything else that would be unique. >>>> > >>>> > > Any ideas / comment would be greatly appreciated. >>>> > >>>> > > -- >>>> > > Post: opend...@googlegroups.com >>>> > > Unsubscribe: opendatakit...@googlegroups.com >>>> > > Options:http://groups.google.com/group/opendatakit?hl=en >>>> > >>>> > -- >>>> > Mitch Sundt >>>> > Software Engineer >>>> > University of Washington >>>> > mitchellsu...@gmail.com >>>> >>>> -- >>>> Post: opend...@googlegroups.com >>>> Unsubscribe: opendatakit...@googlegroups.com >>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>> >>> >>> >>> >>> -- >>> Mitch Sundt >>> Software Engineer >>> University of Washington >>> mitche...@gmail.com >>> >>

Hello Victoria, thanks for sharing this.

I am glad I came across this post. One quick question however, it there a
limit as to how many time one could have the calculate field carry forward
the ID as you illustrated, say if one has multiple separate repeat groups
within the same form?

Any help will be highly appreciated.

Thanks.
Ezra

··· On Monday, January 28, 2013 3:31:54 PM UTC+3, Victoria Trinies wrote: > > Hi Sam, > > I had the same issue, and Yaw helped me out. You can insert the ID through > calculation, where the calculation = the name of the unique ID question. If > you're creating forms as xls and converting to xlm (the only way I know how > to do it) then you'd: > > make sure you have a column called 'calculation' > after your begin repeat, enter a line with type: calculate > read_only: yes > calculation: ${name of ID variable} > > Works like a charm. > > -Victoria > > On Monday, 28 January 2013 11:58:10 UTC, Sam wrote: >> >> Hi Mitch (or anyone else with an answer), >> >> Is there a way to link each form submitted with a personalized unique ID? >> >> >> For example, we are surveying multiple households with multiple "repeat >> groups." Each household is assigned a unique 7-digit ID at the outset of >> the survey-- this is entered as an answer to a survey question. This ID is >> the same for all members of the household. When we export mutiple completed >> surveys to csv files using ODK Briefcase, the only way to tie each "row" >> across multiple CSVs to a given household is to compare the KEY or >> PARENT_KEY column in each CSV file. >> >> Is there a way we could instead or in addition have the 7-digit unique ID >> be the unique identifier that ties all rows or all individual answers of a >> given survey together? >> >> Thanks, >> Sam >> >> On Friday, March 30, 2012 5:54:16 PM UTC, Mitch wrote: >>> >>> That's a different issue. >>> >>> If you have a form with a repeat group, you can use ODK Briefcase to >>> download the submissions to your local machine then use ODK Briefcase >>> (rather than ODK Aggregate) to Export to CSV that form data. This will >>> produce a CSV for the overall form, and a CSV for each repeat group in the >>> form definition. There are columns on the far right of the rows in these >>> files that enable you to pair up the data across these tables. >>> >>> Mitch >>> >>> On Fri, Mar 30, 2012 at 3:53 AM, Humphreys Kabota < humphrey...@investinknowledge.org> wrote: >>> >>>> Mitchell, >>>> I guess I have a similar problem, but specifically with the repeating >>>> groups (rosters): Is there a way that the looped data should be >>>> joined to the parent data rather than having them coming as separate >>>> with the generated parent keys? If this is not possible, then, how >>>> well could I merge the two different data instances (parent and roster >>>> tables); I am using stata 11. >>>> >>>> Humphreys. >>>> >>>> On Mar 29, 11:00 am, Mitch S wrote: >>>> > If the transmission to the server will be greater than 10MB, it is >>>> split >>>> > across multiple submissions. This is to bound the size of the Virtual >>>> > Machine running on the server. >>>> > >>>> > To avoid this problem , specify an instanceID in the form, as defined >>>> here: >>>> https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema For >>>> > ODK Aggregate, you don't need to specify the namespace, just have a >>>> > group in your form. >>>> > >>>> > With ODK Collect 1.1.7 and later, the bind for this element that >>>> replicates >>>> > the instanceID that would otherwise be generated by Aggregate would >>>> be: >>>> > >>>> > >>> > calculate="concat('uuid:', uuid())"/> >>>> > >>>> > You can construct your own instanceID expressions. However, you should >>>> > avoid symbols and punctuation other than colons and dashes since the >>>> > parsing logic within Aggregate is likely fragile if you go wild with >>>> > punctuation (and that is used later on when retrieving images, repeat >>>> > groups, etc.). If you do construct your own values, they must be >>>> less than >>>> > 255 characters long and must be unique across all devices and >>>> submissions. >>>> > >>>> > Mitch >>>> > >>>> > On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated < feltpad...@gmail.com wrote: >>>> > > We are running into a problem where if we send in a submission that >>>> > > has several photos, the submission is getting broken up into several >>>> > > entries in the form's _CORE table (_IS_COMPLETE = 0). >>>> > >>>> > > I do not understand why ODK does this. The issue is that when this >>>> > > happens, there is no way to group together the _CORE rows to know >>>> > > which data was submitted with the same form instance. >>>> > >>>> > > The best option we have come up with is to try and match the data >>>> > > fields in the _CORE table, but this will not guarantee that we are >>>> > > putting the correct pieces of data together - if one user submits >>>> > > multiple form instances that contain identical data in the _CORE >>>> table >>>> > > (and different data in the other tables), then how do we know where >>>> > > the separation is? >>>> > >>>> > > My thought was to create a unique ID that would be a field in the >>>> > > _CORE table and would be generated each time the user creates a new >>>> > > instance of the form. The unique ID could be the username >>>> > > +current_timestamp, or anything else that would be unique. >>>> > >>>> > > Any ideas / comment would be greatly appreciated. >>>> > >>>> > > -- >>>> > > Post: opend...@googlegroups.com >>>> > > Unsubscribe: opendatakit...@googlegroups.com >>>> > > Options:http://groups.google.com/group/opendatakit?hl=en >>>> > >>>> > -- >>>> > Mitch Sundt >>>> > Software Engineer >>>> > University of Washington >>>> > mitchellsu...@gmail.com >>>> >>>> -- >>>> Post: opend...@googlegroups.com >>>> Unsubscribe: opendatakit...@googlegroups.com >>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>> >>> >>> >>> >>> -- >>> Mitch Sundt >>> Software Engineer >>> University of Washington >>> mitche...@gmail.com >>> >>

Ezra,

You insert the id as often as you'd like. The only catch is that the
instance/data name has to be unique.

Yaw

··· -- Need ODK help? Go to http://nafundi.com for custom features, form design, implementation support, and user training for ODK.

On Tue, May 14, 2013 at 6:29 AM, Rwakazooba Ezra Aliija rwakazooba@gmail.com wrote:

Hello Victoria, thanks for sharing this.

I am glad I came across this post. One quick question however, it there a
limit as to how many time one could have the calculate field carry forward
the ID as you illustrated, say if one has multiple separate repeat groups
within the same form?

Any help will be highly appreciated.

Thanks.
Ezra

On Monday, January 28, 2013 3:31:54 PM UTC+3, Victoria Trinies wrote:

Hi Sam,

I had the same issue, and Yaw helped me out. You can insert the ID through
calculation, where the calculation = the name of the unique ID question. If
you're creating forms as xls and converting to xlm (the only way I know how
to do it) then you'd:

make sure you have a column called 'calculation'
after your begin repeat, enter a line with type: calculate
read_only: yes
calculation: ${name of ID variable}

Works like a charm.

-Victoria

On Monday, 28 January 2013 11:58:10 UTC, Sam wrote:

Hi Mitch (or anyone else with an answer),

Is there a way to link each form submitted with a personalized unique ID?

For example, we are surveying multiple households with multiple "repeat
groups." Each household is assigned a unique 7-digit ID at the outset of the
survey-- this is entered as an answer to a survey question. This ID is the
same for all members of the household. When we export mutiple completed
surveys to csv files using ODK Briefcase, the only way to tie each "row"
across multiple CSVs to a given household is to compare the KEY or
PARENT_KEY column in each CSV file.

Is there a way we could instead or in addition have the 7-digit unique ID
be the unique identifier that ties all rows or all individual answers of a
given survey together?

Thanks,
Sam

On Friday, March 30, 2012 5:54:16 PM UTC, Mitch wrote:

That's a different issue.

If you have a form with a repeat group, you can use ODK Briefcase to
download the submissions to your local machine then use ODK Briefcase
(rather than ODK Aggregate) to Export to CSV that form data. This will
produce a CSV for the overall form, and a CSV for each repeat group in the
form definition. There are columns on the far right of the rows in these
files that enable you to pair up the data across these tables.

Mitch

On Fri, Mar 30, 2012 at 3:53 AM, Humphreys Kabota humphrey...@investinknowledge.org wrote:

Mitchell,
I guess I have a similar problem, but specifically with the repeating
groups (rosters): Is there a way that the looped data should be
joined to the parent data rather than having them coming as separate
with the generated parent keys? If this is not possible, then, how
well could I merge the two different data instances (parent and roster
tables); I am using stata 11.

Humphreys.

On Mar 29, 11:00 am, Mitch S mitchellsu...@gmail.com wrote:

If the transmission to the server will be greater than 10MB, it is
split
across multiple submissions. This is to bound the size of the
Virtual
Machine running on the server.

To avoid this problem , specify an instanceID in the form, as defined
here:https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema For
ODK Aggregate, you don't need to specify the namespace, just have a

group in your form.

With ODK Collect 1.1.7 and later, the bind for this element that
replicates
the instanceID that would otherwise be generated by Aggregate would
be:

You can construct your own instanceID expressions. However, you
should
avoid symbols and punctuation other than colons and dashes since the
parsing logic within Aggregate is likely fragile if you go wild with
punctuation (and that is used later on when retrieving images, repeat
groups, etc.). If you do construct your own values, they must be
less than
255 characters long and must be unique across all devices and
submissions.

Mitch

On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated <feltpad...@gmail.com wrote:

We are running into a problem where if we send in a submission that
has several photos, the submission is getting broken up into
several
entries in the form's _CORE table (_IS_COMPLETE = 0).

I do not understand why ODK does this. The issue is that when this
happens, there is no way to group together the _CORE rows to know
which data was submitted with the same form instance.

The best option we have come up with is to try and match the data
fields in the _CORE table, but this will not guarantee that we are
putting the correct pieces of data together - if one user submits
multiple form instances that contain identical data in the _CORE
table
(and different data in the other tables), then how do we know where
the separation is?

My thought was to create a unique ID that would be a field in the
_CORE table and would be generated each time the user creates a new
instance of the form. The unique ID could be the username
+current_timestamp, or anything else that would be unique.

Any ideas / comment would be greatly appreciated.

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsu...@gmail.com

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Thanks Yaw, I going a head to try it out.
Will let you know how it goes.

Regards
Ezra

··· On Tue, May 14, 2013 at 4:30 PM, Yaw Anokwa wrote:

Ezra,

You insert the id as often as you'd like. The only catch is that the
instance/data name has to be unique.

Yaw

Need ODK help? Go to http://nafundi.com for custom features, form
design, implementation support, and user training for ODK.

On Tue, May 14, 2013 at 6:29 AM, Rwakazooba Ezra Aliija rwakazooba@gmail.com wrote:

Hello Victoria, thanks for sharing this.

I am glad I came across this post. One quick question however, it there a
limit as to how many time one could have the calculate field carry
forward
the ID as you illustrated, say if one has multiple separate repeat groups
within the same form?

Any help will be highly appreciated.

Thanks.
Ezra

On Monday, January 28, 2013 3:31:54 PM UTC+3, Victoria Trinies wrote:

Hi Sam,

I had the same issue, and Yaw helped me out. You can insert the ID
through

calculation, where the calculation = the name of the unique ID
question. If

you're creating forms as xls and converting to xlm (the only way I know
how

to do it) then you'd:

make sure you have a column called 'calculation'
after your begin repeat, enter a line with type: calculate
read_only: yes
calculation: ${name of ID variable}

Works like a charm.

-Victoria

On Monday, 28 January 2013 11:58:10 UTC, Sam wrote:

Hi Mitch (or anyone else with an answer),

Is there a way to link each form submitted with a personalized unique
ID?

For example, we are surveying multiple households with multiple "repeat
groups." Each household is assigned a unique 7-digit ID at the outset
of the

survey-- this is entered as an answer to a survey question. This ID is
the

same for all members of the household. When we export mutiple completed
surveys to csv files using ODK Briefcase, the only way to tie each
"row"

across multiple CSVs to a given household is to compare the KEY or
PARENT_KEY column in each CSV file.

Is there a way we could instead or in addition have the 7-digit unique
ID

be the unique identifier that ties all rows or all individual answers
of a

given survey together?

Thanks,
Sam

On Friday, March 30, 2012 5:54:16 PM UTC, Mitch wrote:

That's a different issue.

If you have a form with a repeat group, you can use ODK Briefcase to
download the submissions to your local machine then use ODK Briefcase
(rather than ODK Aggregate) to Export to CSV that form data. This
will

produce a CSV for the overall form, and a CSV for each repeat group
in the

form definition. There are columns on the far right of the rows in
these

files that enable you to pair up the data across these tables.

Mitch

On Fri, Mar 30, 2012 at 3:53 AM, Humphreys Kabota humphrey...@investinknowledge.org wrote:

Mitchell,
I guess I have a similar problem, but specifically with the repeating
groups (rosters): Is there a way that the looped data should be
joined to the parent data rather than having them coming as separate
with the generated parent keys? If this is not possible, then, how
well could I merge the two different data instances (parent and
roster

tables); I am using stata 11.

Humphreys.

On Mar 29, 11:00 am, Mitch S mitchellsu...@gmail.com wrote:

If the transmission to the server will be greater than 10MB, it is
split
across multiple submissions. This is to bound the size of the
Virtual
Machine running on the server.

To avoid this problem , specify an instanceID in the form, as
defined

here:
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema For

ODK Aggregate, you don't need to specify the namespace, just have a

group in your form.

With ODK Collect 1.1.7 and later, the bind for this element that
replicates
the instanceID that would otherwise be generated by Aggregate would
be:

<bind nodeset="/data/meta/instanceID" type="string"
readonly="true()"

calculate="concat('uuid:', uuid())"/>

You can construct your own instanceID expressions. However, you
should
avoid symbols and punctuation other than colons and dashes since
the

parsing logic within Aggregate is likely fragile if you go wild
with

punctuation (and that is used later on when retrieving images,
repeat

groups, etc.). If you do construct your own values, they must be
less than
255 characters long and must be unique across all devices and
submissions.

Mitch

On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated <feltpad...@gmail.com wrote:

We are running into a problem where if we send in a submission
that

has several photos, the submission is getting broken up into
several
entries in the form's _CORE table (_IS_COMPLETE = 0).

I do not understand why ODK does this. The issue is that when
this

happens, there is no way to group together the _CORE rows to know
which data was submitted with the same form instance.

The best option we have come up with is to try and match the data
fields in the _CORE table, but this will not guarantee that we
are

putting the correct pieces of data together - if one user submits
multiple form instances that contain identical data in the _CORE
table
(and different data in the other tables), then how do we know
where

the separation is?

My thought was to create a unique ID that would be a field in the
_CORE table and would be generated each time the user creates a
new

instance of the form. The unique ID could be the username
+current_timestamp, or anything else that would be unique.

Any ideas / comment would be greatly appreciated.

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsu...@gmail.com

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/93v4lCzf4YI/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Yaw, Just to confirm by instance/data name, I gather you mean the "name"
column in the xls file, am I right?

··· On Tue, May 14, 2013 at 4:39 PM, Rwakazooba Ezra Aliija < rwakazooba@gmail.com> wrote:

Thanks Yaw, I going a head to try it out.
Will let you know how it goes.

Regards
Ezra

On Tue, May 14, 2013 at 4:30 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

Ezra,

You insert the id as often as you'd like. The only catch is that the
instance/data name has to be unique.

Yaw

Need ODK help? Go to http://nafundi.com for custom features, form
design, implementation support, and user training for ODK.

On Tue, May 14, 2013 at 6:29 AM, Rwakazooba Ezra Aliija rwakazooba@gmail.com wrote:

Hello Victoria, thanks for sharing this.

I am glad I came across this post. One quick question however, it there
a
limit as to how many time one could have the calculate field carry
forward
the ID as you illustrated, say if one has multiple separate repeat
groups
within the same form?

Any help will be highly appreciated.

Thanks.
Ezra

On Monday, January 28, 2013 3:31:54 PM UTC+3, Victoria Trinies wrote:

Hi Sam,

I had the same issue, and Yaw helped me out. You can insert the ID
through

calculation, where the calculation = the name of the unique ID
question. If

you're creating forms as xls and converting to xlm (the only way I
know how

to do it) then you'd:

make sure you have a column called 'calculation'
after your begin repeat, enter a line with type: calculate
read_only: yes
calculation: ${name of ID variable}

Works like a charm.

-Victoria

On Monday, 28 January 2013 11:58:10 UTC, Sam wrote:

Hi Mitch (or anyone else with an answer),

Is there a way to link each form submitted with a personalized unique
ID?

For example, we are surveying multiple households with multiple
"repeat

groups." Each household is assigned a unique 7-digit ID at the outset
of the

survey-- this is entered as an answer to a survey question. This ID
is the

same for all members of the household. When we export mutiple
completed

surveys to csv files using ODK Briefcase, the only way to tie each
"row"

across multiple CSVs to a given household is to compare the KEY or
PARENT_KEY column in each CSV file.

Is there a way we could instead or in addition have the 7-digit
unique ID

be the unique identifier that ties all rows or all individual answers
of a

given survey together?

Thanks,
Sam

On Friday, March 30, 2012 5:54:16 PM UTC, Mitch wrote:

That's a different issue.

If you have a form with a repeat group, you can use ODK Briefcase to
download the submissions to your local machine then use ODK Briefcase
(rather than ODK Aggregate) to Export to CSV that form data. This
will

produce a CSV for the overall form, and a CSV for each repeat group
in the

form definition. There are columns on the far right of the rows in
these

files that enable you to pair up the data across these tables.

Mitch

On Fri, Mar 30, 2012 at 3:53 AM, Humphreys Kabota humphrey...@investinknowledge.org wrote:

Mitchell,
I guess I have a similar problem, but specifically with the
repeating

groups (rosters): Is there a way that the looped data should be
joined to the parent data rather than having them coming as separate
with the generated parent keys? If this is not possible, then, how
well could I merge the two different data instances (parent and
roster

tables); I am using stata 11.

Humphreys.

On Mar 29, 11:00 am, Mitch S mitchellsu...@gmail.com wrote:

If the transmission to the server will be greater than 10MB, it is
split
across multiple submissions. This is to bound the size of the
Virtual
Machine running on the server.

To avoid this problem , specify an instanceID in the form, as
defined

here:
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema For

ODK Aggregate, you don't need to specify the namespace, just have
a

group in your form.

With ODK Collect 1.1.7 and later, the bind for this element that
replicates
the instanceID that would otherwise be generated by Aggregate
would

be:

<bind nodeset="/data/meta/instanceID" type="string"
readonly="true()"

calculate="concat('uuid:', uuid())"/>

You can construct your own instanceID expressions. However, you
should
avoid symbols and punctuation other than colons and dashes since
the

parsing logic within Aggregate is likely fragile if you go wild
with

punctuation (and that is used later on when retrieving images,
repeat

groups, etc.). If you do construct your own values, they must be
less than
255 characters long and must be unique across all devices and
submissions.

Mitch

On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated <feltpad...@gmail.com wrote:

We are running into a problem where if we send in a submission
that

has several photos, the submission is getting broken up into
several
entries in the form's _CORE table (_IS_COMPLETE = 0).

I do not understand why ODK does this. The issue is that when
this

happens, there is no way to group together the _CORE rows to
know

which data was submitted with the same form instance.

The best option we have come up with is to try and match the
data

fields in the _CORE table, but this will not guarantee that we
are

putting the correct pieces of data together - if one user
submits

multiple form instances that contain identical data in the _CORE
table
(and different data in the other tables), then how do we know
where

the separation is?

My thought was to create a unique ID that would be a field in
the

_CORE table and would be generated each time the user creates a
new

instance of the form. The unique ID could be the username
+current_timestamp, or anything else that would be unique.

Any ideas / comment would be greatly appreciated.

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsu...@gmail.com

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/93v4lCzf4YI/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Yaw, I thought I could attach a clip of what my sheet looks like, all the
calculate rows come right after a repeat group(hidden for size purposes).

From the exported data however,
It only seems to work for "HHMemberSurveyID" the other csv do not have the
id replicate

any ideas would be appreciated.

apologies in case of any trouble viewing the image

Thanks.
regards.
Ezra
[image: Inline image 1]

image

··· On Tue, May 14, 2013 at 4:55 PM, Rwakazooba Ezra Aliija < rwakazooba@gmail.com> wrote:

Yaw, Just to confirm by instance/data name, I gather you mean the "name"
column in the xls file, am I right?

On Tue, May 14, 2013 at 4:39 PM, Rwakazooba Ezra Aliija < rwakazooba@gmail.com> wrote:

Thanks Yaw, I going a head to try it out.
Will let you know how it goes.

Regards
Ezra

On Tue, May 14, 2013 at 4:30 PM, Yaw Anokwa yanokwa@nafundi.com wrote:

Ezra,

You insert the id as often as you'd like. The only catch is that the
instance/data name has to be unique.

Yaw

Need ODK help? Go to http://nafundi.com for custom features, form
design, implementation support, and user training for ODK.

On Tue, May 14, 2013 at 6:29 AM, Rwakazooba Ezra Aliija rwakazooba@gmail.com wrote:

Hello Victoria, thanks for sharing this.

I am glad I came across this post. One quick question however, it
there a
limit as to how many time one could have the calculate field carry
forward
the ID as you illustrated, say if one has multiple separate repeat
groups
within the same form?

Any help will be highly appreciated.

Thanks.
Ezra

On Monday, January 28, 2013 3:31:54 PM UTC+3, Victoria Trinies wrote:

Hi Sam,

I had the same issue, and Yaw helped me out. You can insert the ID
through

calculation, where the calculation = the name of the unique ID
question. If

you're creating forms as xls and converting to xlm (the only way I
know how

to do it) then you'd:

make sure you have a column called 'calculation'
after your begin repeat, enter a line with type: calculate
read_only: yes
calculation: ${name of ID variable}

Works like a charm.

-Victoria

On Monday, 28 January 2013 11:58:10 UTC, Sam wrote:

Hi Mitch (or anyone else with an answer),

Is there a way to link each form submitted with a personalized
unique ID?

For example, we are surveying multiple households with multiple
"repeat

groups." Each household is assigned a unique 7-digit ID at the
outset of the

survey-- this is entered as an answer to a survey question. This ID
is the

same for all members of the household. When we export mutiple
completed

surveys to csv files using ODK Briefcase, the only way to tie each
"row"

across multiple CSVs to a given household is to compare the KEY or
PARENT_KEY column in each CSV file.

Is there a way we could instead or in addition have the 7-digit
unique ID

be the unique identifier that ties all rows or all individual
answers of a

given survey together?

Thanks,
Sam

On Friday, March 30, 2012 5:54:16 PM UTC, Mitch wrote:

That's a different issue.

If you have a form with a repeat group, you can use ODK Briefcase to
download the submissions to your local machine then use ODK
Briefcase

(rather than ODK Aggregate) to Export to CSV that form data. This
will

produce a CSV for the overall form, and a CSV for each repeat group
in the

form definition. There are columns on the far right of the rows in
these

files that enable you to pair up the data across these tables.

Mitch

On Fri, Mar 30, 2012 at 3:53 AM, Humphreys Kabota humphrey...@investinknowledge.org wrote:

Mitchell,
I guess I have a similar problem, but specifically with the
repeating

groups (rosters): Is there a way that the looped data should be
joined to the parent data rather than having them coming as
separate

with the generated parent keys? If this is not possible, then, how
well could I merge the two different data instances (parent and
roster

tables); I am using stata 11.

Humphreys.

On Mar 29, 11:00 am, Mitch S mitchellsu...@gmail.com wrote:

If the transmission to the server will be greater than 10MB, it
is

split
across multiple submissions. This is to bound the size of the
Virtual
Machine running on the server.

To avoid this problem , specify an instanceID in the form, as
defined

here:
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema For

ODK Aggregate, you don't need to specify the namespace, just
have a

group in your form.

With ODK Collect 1.1.7 and later, the bind for this element that
replicates
the instanceID that would otherwise be generated by Aggregate
would

be:

<bind nodeset="/data/meta/instanceID" type="string"
readonly="true()"

calculate="concat('uuid:', uuid())"/>

You can construct your own instanceID expressions. However, you
should
avoid symbols and punctuation other than colons and dashes since
the

parsing logic within Aggregate is likely fragile if you go wild
with

punctuation (and that is used later on when retrieving images,
repeat

groups, etc.). If you do construct your own values, they must be
less than
255 characters long and must be unique across all devices and
submissions.

Mitch

On Thu, Mar 29, 2012 at 10:33 AM, Feltpad Incorporated <feltpad...@gmail.com wrote:

We are running into a problem where if we send in a submission
that

has several photos, the submission is getting broken up into
several
entries in the form's _CORE table (_IS_COMPLETE = 0).

I do not understand why ODK does this. The issue is that when
this

happens, there is no way to group together the _CORE rows to
know

which data was submitted with the same form instance.

The best option we have come up with is to try and match the
data

fields in the _CORE table, but this will not guarantee that we
are

putting the correct pieces of data together - if one user
submits

multiple form instances that contain identical data in the
_CORE

table
(and different data in the other tables), then how do we know
where

the separation is?

My thought was to create a unique ID that would be a field in
the

_CORE table and would be generated each time the user creates
a new

instance of the form. The unique ID could be the username
+current_timestamp, or anything else that would be unique.

Any ideas / comment would be greatly appreciated.

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options:http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsu...@gmail.com

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google
Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit/93v4lCzf4YI/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.