Pulldata to Single Choice and Single Multiple Fields

Hello, I’m an amateur user of Kobo’s .xls form builder, and I’ve been struggling during the past days while trying to create a form that preloads the answers of the questions by writing the unique ID of a participant. I want to create a form that’s capable of both inscribing a new participant to an education project and updating the profile data of the participants already inscribed. The idea is to fill the ID field, and if the ID had already been registered it should preload the subsequent fields in order for the surveyor to change only the variables that have have different data. I know I can use pulldata for text-type questions, but it returns error when I try to deploy the form:

My guess is that the usage of pulldata with choice questions is the source of the error, so I would like to know how should I deploy the functions for the single choice, or if you consider that it is a totally different issue altogether. I would upload the xls and csv files but since I’m a new user I can’t upload them. Thanks in advance for any help you may provide.

1 Like

I’ve bumped up your ‘trust level’; can you try to upload again the form your are trying to deploy, thanks.

1 Like

Thank you very much for the prompt response. This is the xls form

Borrador - Formulario de Censo de Participantes - HUB Edutech.xlsx (102.0 KB)

And this is the pulldata csv (these are dummies, I’m not using real data yet):

censoOrd.csv (2.6 KB)

Thanks for the help, kind regards.

First, you should run your form thru XLSForm Online to pickup any basic ‘syntax’ errors. Then, after the form deploys to Kobo and runs ok - but it is still misbehaving - post back what your expected vs actual results are, and we can proceed from there.

1 Like

Good morning, thanks for the response. It seems the issue actually aren’t single choice or select multiple type of questions, but rather that I’m trying to pull string data into a geopoint field.

This strikes me as odd, given that I specifically set that particular field as numerical in the response sheet before converting it to csv. This implies that I have to take a totally different approach from what I was trying to do, and more than likely won’t have to preload data to the form. Thank you for your help, it has given me plenty of insight.

Looking at your form, you do appear to be trying to pull in a geopoint from your external censoOrd.csv dataset.

However, the field DireccionResidencia you are pulling it in from is empty (!)

Have you tried actually populating this field with an appropriately formatted geopoint string; eg

10.259034 -85.585049 0 0

1 Like

Hello, that’s actually a very unfortunate accident. I’ve had issues with the function to fill that column, and here I thought I had sorted it. I’ll fix it and let you know how it goes.

Kind regards.

Make sure you get the format precisely right, or it wont work.

Each point is represented as four numbers separated by spaces: latitude, longitude, altitude in meters, and accuracy radius in meters

Specifically, space-separated numbers (not comma), latitude then longitude, and you have to supply an altitude and accuracy value (but you can default these to 0 if you dont have the actual measurement).

1 Like

Greetings, the error still persists. I made the following changes to the csv file:

censoOrd v2.csv (2.9 KB)

Keep in mind that i’ve named the updated csv as v2, this is only to differentiante from the file posted previously. The uploaded file in media settings and the reference in the pulldata function maintain the previous name. Thanks for all the help, kind regards.

I took another look at your data file. Although you do now appear to have correctly formatted geopoint for DireccionResidencia, your ID numbers appear to have been mangled (by whatever process you used to generate the CSV…)

Please validate that your raw data is correctly populated and formatted before trying to deploy your form. Even if your form ‘compiles’ without any errors, if the data is malformed it wont matter.

1 Like

Hello, I have corrected the csv file, yet I still get the error:

censoOrd v3.csv (2.7 KB)

Guess that a simpler workaround could be not preloading data using the update information option of the form, but rather setting a select multiple field which redirects to the specific questions to be updated and filling them manually. The database wouldn’t be readily available to use once exported, but maybe it would be easier to use the participants unique ID to search and draw the most recent information in every excel column for every unique participant (row).

Thanks for all the support and patience.

Can you please repost your (corrected) form. The above form appears to still have errors.

1 Like

Greetings and thanks for the reply. The form was already corrected, but the issue persists, even though it doesn’t seem that there’re syntaxis mistakes.

Borrador - Formulario de Inscripción de Participantes - HUB Edutech.xlsx (15.7 KB)

I tried deploying the xls without the pulldata options. The form was able to go live and I was able to send data:

It seems the issue is the configuration of pulldata for certain fields, but it’s hard to tell which. I’ll keep doing tests and will notify you if I discover anything relevant. Thank you, kind regards

Please note, your new form still has duplicate names also…

As it happens, Kobo will silently(!) rename these when you upload your form, but this really isn’t behavior you should rely upon (and it will cause form validation tools- like XLSForm Online - to fail). Please make sure to use unique names for all your questions, including notes.

But going back to your original question…

The validation error you are getting appears to be a result of pyxform performing a specific check for geopoint controls in particular. In your case, you are performing a calculated geopoint, and pyxform is checking whether the result of your calculation is going to be of the right type. However, it only performs this static validation check once, when you deploy the form, and using the initial default form values only (and AFAIK not actually pulling any data!). So this results in a false-negative validation error, because it cannot determine whether the value that is (eventually…) going to be pulled in as a result of performing the pulldata() calculation will match a geopoint string.

But you can trick it by making sure the this pulldata() calculation is not run during this initial pre-deployment validation step, by making it conditional on having a valid id number to lookup (which only gets entered when you actually fill in the form; initially id_participante will be null).

if(${id_participante}!='', pulldata(‘censoOrd’,‘DireccionResidencia’,‘IDParticipante’,${id_participante}), '')

Borrador - Formulario de Censo de Participantes - HUB Edutech.xlsx (130.8 KB)

(I also fixed your duplicate names while i was at it…)

If you do this, your form should now deploy without any error, and it appears to work as you intend, correctly pulling in a geopoint location if I enter a recognized id from your sample csv dataset:

I’ve tested this only against Enketo; I dont know if or how well your form will work against KoboCollect so YMMV…

[Aside, this is a similar false-negative validation error - along with a similar workaround - to what I described recently here]

All that aside, again, if you are seeing any problems with your form(s), please make sure your raw data is correctly populated and formatted, and I recommend running your form thru the XLSForm Online validator and fixing any errors it reports before proceeding.

1 Like

Thank you very much, the form now works correctly. I honestly hadn’t thought of the possibility that geopoint worked as a calculated field, thought it was more like a database for latitudes and longitudes. Although now it seems a bit obvious, given that the raw value of the field looks like a concatenation of both variables.

On a sidenote, in this project’s particular case we don’t intend on using another collector aside of the web browser version of Enketo, mostly due to reasons of practicality and expediency, so it will most likely work well.

Thank you very much for all the support, kind regards.

1 Like

You need to be a bit mindful of calculations, because in principle they can be re-evaluated constantly during form-filling; not just once at the beginning, and not just only once after you might logically think they are. In your case, having a calculated result for a geopoint widget could well result in whatever location the user might manually enter getting subsequently clobbered - or nulled out! - by the associated calculation being re-executed.

Hence my caveat that I dont know how well your form might behave under KoboCollect… :no_mouth:

1 Like