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.
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.
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.
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.
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.
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.
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.
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.
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.
···
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.
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.
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
>
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
>>
>
···
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.
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.
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.
···
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
>>>
>>
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
>>>
>>
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
