Hello Kal_Lam, I have the same problem of export failure. From your explanations given to other KOBO community members, I understand that it may be due to problems with the design of the questionnaires but I can’t find the solution. Can you please help me?
Username: xxxxxxx
password: xxxxxxx
The two questionnaires that fail to export are “Guide d’enquête Parcelle” and “Guide d’enquête Ménage”.
Thank you in advance for your help
@Vladoos, did you try downloading your data in XLS (Legacy) format?
Hi Kal_Lam,
Yes I tried, but but this solution does not allow to include data from all versions (if I understood correctly). Is there another solution that allows this?
On the other hand, I have just noticed another problem : for the 3 questionnaires on my account, it is not possible to modify the data on tables (by clicking on the little pencil on the left). An error message appears.
Thank you in advance for your precious help.
Hi @Vladoos, I will look into this now 
Hi @Vladoos, I’m working on a fix but please use the option to export only the latest version until it can be deployed into production.
Hi Josh,
Thank you for your reply, but I think that the two problems are still there. As a reminder, here they are:
Hi @Vladoos, the fix has been completed but not yet deployed onto the production servers, so unfortunately it will only reflect in the next week or two. Your exports will continue to fail when done with all versions until then.
Regarding your second point, can you please clarify what happens when you try modifying the data in the table? Are all the records affected or only some?
Hi Josh,
OK, we will wait for the fix to be deployed.
Regarding the second point, when we click on the pencil to modify the online tables (see attached “capture1”), an error message appears (see attached “capture2”). It is impossible to modify data in the online table.
I hope my explanations are clearer this time.
Thank you,
Hi @Vladoos, sorry for missing this. Please ping me with the @Josh in your message so I get a notification
This may be related to a similar versioning issue. Since editing your submissions in Enketo always uses the latest deployed version of the form, if this is incompatible with the submission then there will be an issue. To get around this please use the bulk editing feature for these submissions: Editing Responses in Multiple Submissions — KoBoToolbox documentation
Hi @Josh,
Thank you for your reply. So I understand that when we have multiple versions of a survey, Enketo no longer works, is that correct?
I think your suggestion may help me to solve the problem, but only partly because the data from repeat group questions is not visible on the online table. Is there any way to see (and edit) this data before downloading the database ?
Hi @Vladoos, if you have multiple form versions Enketo will still work under most circumstances but if your form has been significantly changed, then trying to edit submissions done on the old version of the form may not be compatible with the latest version. Having said that, this may actually be a different issue. I will look into it
Hi @Vladoos, I apologize for the delay in this. It looks like the issue lies in the upgrade to Enketo that was done a few weeks ago. The bug seems to be that when using selected-at() and or together in your choice_filter column, the order that you write the constraint matters. For example, if I have selected-at(${something}, 0)=filter or selected-at(${something}, 1)=filter I see the same issue you get, but if I change the order to filter=selected-at(${something}, 0) or filter=selected-at(${something}, 1) it works as expected. I will create an issue for this.
Having said that, I would suggest (if I understand your form correctly) that you replace the very long choice filters that look like selected-at(${cult_perenne},0)=filter2 or selected-at(${cult_perenne},1)=filter2 or ... with the contains() method: contains(${cult_perenne}, filter2). It also seems to speed up the form quite significantly.
If you make either of those changes (change the order or using contains()) and then redeploy, you should be able to edit your submissions again without error — because editing uses the latest deployed form version.
Hi @Josh , thank you for your reply. I replaced the choice filter “selected-at()” by “contains()” as recommended and I think it is better. But now there is a different error message that appears and I don’t know how to solve this new problem.
Here are attached the messages that appear for 2 of the 3 surveys.
Also, it is still impossible to export database in XLS for the “Guide d’enquête Parcelle” survey (including data from all versions) since you fixed the problem 14 days ago. However, we can now export the databases for the other surveys.
Hi @Vladoos, oh dear. I’ll investigate this 
Yes, the fix has just been deployed on the HHI server and is scheduled for OCHA in the coming days:
Hi @Josh,
Sorry for my late repy. It is now possible to export all the databases in my account, thank you very much for that!
However, I still get error messages when I try to edit the tables in 2 of the 3 questionnaires in my account. Please see my post above to see what this is about.
Thank you for your help
Hi @Vladoos, that’s great! I’ve spent some time looking into this issue and battling to reproduce it with a simple form (I can reproduce it with your form). However I have found that the problematic cell is L81 in your form “Guide d’enquête Parcelle” (your relevant value for the repeat group Conso_Inter). If I change this from ${ci}="oui" to the equivalent of ${nb_ci}!="" it no longer gives me the error. Can you make this change, redeploy and then try editing again?
Hi @Josh. If I change in the cell L81 ${ci}=“oui” by ${ci_nb}!="", I can’t redeploy because there is no element with the name ${ci_nb}!="". I tried with ${nb_ci}!="" (existing name) but without success, the same error message as with ${ci}=“oui” appears…
I also noticed in the survey “Guide d’enquête Parcelle” that the message error could concern different cells (ex: type_produitOP) depending on the line you select but always with the same error message : Failed to execute ‘evaluate’ on ‘XPathEvaluator’: parameter 2 is not of type ‘Node’.
And it is th same error message for the survey “Guide d’enquête ménage”. Unfortunately, I don’t know what it means.
Hi @Vladoos, sorry, yes that was an unfortunate typo — I’ve edited my previous message with the correct variable name.
Hmmm that’s concerning… this is a strange one. I’ll continue investigating.
I’ve noticed recently that doubly nested repeat groups sometimes have strange issues so if you can avoid them in future forms that would be safer 
