Generating key to relate tables

Dear all,

I am using ODK collect. Since we need to collect numerous data, I want to
split the dataforms into modules. I plan to do this either in the form
itself (e.g. by using a few conditional questions to direct the user to the
relevant questions) or by generating seperate forms. Since there is so much
data to collect, I prefer to generate seperate forms as the form may become
too large if I build all modules into one form.

My question is how I can make sure that the tables can be related in
Aggregate by a key-ID. The field technicians can manually enter a unique ID
for each entrance and form, but mistakes are quickly made... Is there a way
how this can be prevented? Or is there an alternative way to do this?

I was thinking about a selection menu (once an ID is manually entered (e.g.
text or numerical field), the ID is loaded into the memory of the tablet
and can be withdrawn again by a pull down menu). This could help a lot
already. However people can still make errors, which would be problematic
for relating all tables...

Hope someone has found a good solution for this... Thanks in advance!

Kind regards,

Eddy

We often recommend using barcodes (or QR codes) for entering identifiers
that will be used to link two or more form submissions.

This introduces a paper or adhesive-label artifact into your data
collection process, but it is the easiest way to handle these situations.

You could even use the Zebra Printer Driver (
https://opendatakit.org/use/sensors/zebra-printer-driver/ ) to generate
this barcode in the field along with some readable identifying information
and then scan that barcode into the other forms; the printout can be saved
for record keeping and possible follow-ups.

··· On Fri, Oct 30, 2015 at 12:08 PM, Eddy Rellum <4estsense@gmail.com> wrote:

Dear all,

I am using ODK collect. Since we need to collect numerous data, I want to
split the dataforms into modules. I plan to do this either in the form
itself (e.g. by using a few conditional questions to direct the user to the
relevant questions) or by generating seperate forms. Since there is so much
data to collect, I prefer to generate seperate forms as the form may become
too large if I build all modules into one form.

My question is how I can make sure that the tables can be related in
Aggregate by a key-ID. The field technicians can manually enter a unique ID
for each entrance and form, but mistakes are quickly made... Is there a way
how this can be prevented? Or is there an alternative way to do this?

I was thinking about a selection menu (once an ID is manually entered
(e.g. text or numerical field), the ID is loaded into the memory of the
tablet and can be withdrawn again by a pull down menu). This could help a
lot already. However people can still make errors, which would be
problematic for relating all tables...

Hope someone has found a good solution for this... Thanks in advance!

Kind regards,

Eddy

--

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/d/optout.

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

Dear Mitch,

Thanks for the feedback. It is a solution, but not a very practical one for
my case. Anyway, thanks for this.

regards,

Eddy

··· On Saturday, October 31, 2015 at 12:23:45 AM UTC+1, Mitch Sundt wrote: > > We often recommend using barcodes (or QR codes) for entering identifiers > that will be used to link two or more form submissions. > > This introduces a paper or adhesive-label artifact into your data > collection process, but it is the easiest way to handle these situations. > > You could even use the Zebra Printer Driver ( > https://opendatakit.org/use/sensors/zebra-printer-driver/ ) to generate > this barcode in the field along with some readable identifying information > and then scan that barcode into the other forms; the printout can be saved > for record keeping and possible follow-ups. > > > On Fri, Oct 30, 2015 at 12:08 PM, Eddy Rellum <4est...@gmail.com > wrote: > >> Dear all, >> >> >> I am using ODK collect. Since we need to collect numerous data, I want to >> split the dataforms into modules. I plan to do this either in the form >> itself (e.g. by using a few conditional questions to direct the user to the >> relevant questions) or by generating seperate forms. Since there is so much >> data to collect, I prefer to generate seperate forms as the form may become >> too large if I build all modules into one form. >> >> My question is how I can make sure that the tables can be related in >> Aggregate by a key-ID. The field technicians can manually enter a unique ID >> for each entrance and form, but mistakes are quickly made... Is there a way >> how this can be prevented? Or is there an alternative way to do this? >> >> I was thinking about a selection menu (once an ID is manually entered >> (e.g. text or numerical field), the ID is loaded into the memory of the >> tablet and can be withdrawn again by a pull down menu). This could help a >> lot already. However people can still make errors, which would be >> problematic for relating all tables... >> >> Hope someone has found a good solution for this... Thanks in advance! >> >> Kind regards, >> >> >> Eddy >> >> -- >> -- >> Post: opend...@googlegroups.com >> Unsubscribe: opendatakit...@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...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >

Hi Eddy,

How big is your form (precisely how many variables are there)?

We used to work with forms with 3,000 variables, lots of linked repeats, each repeat may have 40 members or so and it worked just fine.

Trung

Hi Trung,

Thanks for this useful feedback. I am always a bit careful in creating long
and complex forms, but as I understand from you, this is no problem at all.
The forms I am generating are not that long at all as yours are. So are you
combining all your things into one form? What is the limiting factor here,
what cautions I should take in the design? I know photos/videos/recordings
are, but any idea what may other characteristics may cause hickups in the
forms? The thing is that I want to create generic modular forms that can be
used over the years by project partners (for monitoring) that manage
projects with several themes. As such, I need to think things through very
carefully in the design. Thanks for your feedback.

Regards, Eddy

··· On Saturday, October 31, 2015 at 8:54:10 PM UTC+1, Trung wrote: > > Hi Eddy, > > How big is your form (precisely how many variables are there)? > > We used to work with forms with 3,000 variables, lots of linked repeats, > each repeat may have 40 members or so and it worked just fine. > > Trung > >