Hello,
I am creating a brand new form. I was able to publish it, but the updates did not reflect in the form. The error I receive is 'Error converting XLSForm' I can't find the reason why this is happening. The last question type I added was a select one type. I checked field names and it is correct. I can't update or refresh the form at all. I went into AGOL and made sure the select one question field name was added along with the domain. When I try to update the form in Survey123 Connect even with the new field added into AGOL, it will not work. I keep receiving the same error over and over. I sure hope someone can help. Thanks
Solved! Go to Solution.
Hey Doug,
Values set for bind::esri:fieldType were working just fine, but when a value for the bind::type column was set for select_one/multiple questions, that's where the error came in.
Looked into it a bit more and there was a thread from 2019 indicating that it was a known issue however it doesn't seem to be addressed. Might bring it up again in a thread/open a support case when I have a chance!
Things that jump out at me
instance name with special chars concat(${Survey_Date}," || ", ${Lead_ECI_Name}, " || ", ${Survey_Type})
You have the allowupdates thing in 2 places. Its just the bind::esri:parameters one.
I do not think you need to have the allowAdds one there, at least I have never used it.
Start there and see hopefully that is it.
Hi Doug,
I have learned so much from you in this forum! For the instance name, it actually works. I have used these special chars in other forms without errors. It makes the inbox records in the form easier to read. Regarding the allowUpdates, I will use the bind::esri:parameters field only. I had used this format before, with the parameters field and did not experience any errors. I have now learned that the bind::type field should NOT be used for type for single and multichoice questions. I suspect using the parameters field for allowUpdates should also NOT be used in conjunction with bind::esri:parameters. Learning things! Thanks again for your quick response.
Hey there,
I'm not entirely sure why, but the survey seems to fail when "string" values for "bind::type" in column S are set for select_one/multiple questions.
When the bind::type values for "string" are removed in column S from rows 21-53 for select_one/multiple questions, the survey seems to load properly.
Troubleshooting process was deleting rows to see what caused the issue. I first deleted the repeat and it loaded properly. Then when re-adding the repeat, the survey failed, thus the error was in the repeat.
I then started removing groups within the repeat. I first removed all but one group. The survey failed, so the issue was within the group.
I then removed all but one value within the group which seemed to work (the bind::type was string). Re-introducing the remainder of the group, it failed again. I then deleted all the parameters apart from the field name to see if it would work which it did.
It was then found to be the bind::type values that were causing the issues. Furthermore, it was specifically the bind::types of string that was causing the survey to fail, and only for select_one/multiple questions.
I'm not sure if this is expected behaviour, but it does seem to be a fix for your issue.
EDIT: This seems to be part of a known issue dating back to 2019 based on this thread.
Hi Vinzafy,
Many thanks for your analysis of the xls sheet for bind field. It was definitely the bind::type values that caused the error. I have removed the bind::types for all single and multi choice questions and was able to update and publish successfully. Thank you!
I almost never use the bind type esri except for null. It should all work based on the question type just fine.
Hey Doug,
Values set for bind::esri:fieldType were working just fine, but when a value for the bind::type column was set for select_one/multiple questions, that's where the error came in.
Looked into it a bit more and there was a thread from 2019 indicating that it was a known issue however it doesn't seem to be addressed. Might bring it up again in a thread/open a support case when I have a chance!
Glad that's working on your end too! Weird one, but seems to be a known issue dating back to 2019 based on this thread. Might be worth bringing up again when I have the chance!