Has there been a change in 3.13.234? prior to this you could use numbers stored as text for choice lists in the name. This doesn't appear to be the case anymore? or is it a bug? Can anyone comment?
Thanks
found the issue. appears that field=string(${number field) is now required for doing dynamic lookups if your name has numbers.
thanks for the update. 😞
I have been having massive issues with the pull data function since the last update. It broke a dozen of my existing surveys. Can you explain your issue in a little more detail? When you say name has numbers, do you mean the name of the column in the .csv? or the name in the survey form?
I had a column of unused data in the csv along for the ride that did not have a column header, and that broke the pull data function for anything referencing that sheet. I also have an issue pulling data on an ID over 8 digits, but I did suspect it was related to the number/text thing. I've been trying to get acknowledgement through the support line for 2 weeks and haven't received any confirmation of issues with dynamic lookups.
I also am having issues with the Inbox not showing the values within a select one choice list contained in a Repeat.
This might be a longstanding issue. Did it used to work? I know the Inbox has long been glitchy on showing values from a pull data once you click on it. I have the naming convention to show the asset name from the select-one choice list. So i can see who/what it is in the inbox, but when i open the survey the data isn't there. That's in a non-repeat pull data.
Name as in the Choice Name or value that gets stored in the db.
This is how we handle dynamic lookups we don't use pulldata function.
Cascading and external selects—ArcGIS Survey123 | Documentation
You may get a better response posting your survey here and asking what's the issue.
Hi @ldurland,
Can you please share your XLSForm (xlsx file and media folder), ensure you include the CSV files for the lookups and pulldata etc.
In 3.13 there were improvements to handling text/number lookups in external CSV files, as previously leading zeros were dropped and text strings that appeared as numbers got converted incorrectly. With 3.13 many of these issues got resolved. Depending on how you have configured your survey, there could be a conflict with string/number handling.
I noticed you have posted a few issues recently that you are encoutering with 3.13 since the release. I would recommend if possible to test your surveys with the beta builds and release candidate builds that are available on the Early Adopter Community (EAC) during developement and prior to a release. This feedback is important to the development process, and also helps customers get ahead of any upcoming changes and fixes.
Regards,
Phil.
Is there documentation on the changes in 3.13 beyond the "What's New" piece? Please share a link if so. Respectfully, the recommendation to test our surveys against all the beta builds is unrealistic for many users. I (and I'm sure many others) are completely full doing our work, and we can't take time to constantly test new beta versions. I don't speak for @ldurland but I had a lot of existing functionality disrupted with this last upgrade, and there wasn't any heads up and I still can't find detailed documentation about all the changes. My form and media folder has been shared through a support case for 2 weeks now with zero movement. I know you were addressing @ldurland but their challenges are similar to mine.
Well said @PhilipMarty and couldn't agree more. we are probably pushing 100 surveys. multiple that by 5 10 minutes a survey review and or update and well that time adds up. Time that we dont have and not to mention the time to even test beta. Don't get me wrong we really like the product and the updates, but inconsistencies are consistent. What happens is because of a bug or expected functionality that doesn't meet the expectations of the end users, we (end users) typically figure out a work around. and if its a 6 months, a year or more before said issue is fixed and breaks said workaround well that's where we are today. I know the current way of product development is to get the end users to qaqc but like @PhilipMarty stated some documentation would be nice or a heads up that by the way we changed a feature that will likely need addressing for your surveys.
Totally understand your comments and frustration when things stop working from release to release. We do our best to avoid this, but sometimes the unknown is our worst enemy, as we do not get to see everyones forms and how they have configured them, and we can not test ourselves with everyones forms before a release.
Often these issues occur when a bug is fixed or an enhancement is made with best intentions, to resolve issues reported by other customers (often high priority or escalated). When these are fixed but workarounds have been used in place by other customers, things may stop working as they did before, but in reality they are now working the correct way.
The best place to know about upcoming changes is the Early Adopter Community (EAC). Here we list detailed upcoming changes in regular announcments, have feature documentation, list known limitations or changes, and have forums where we can discuss the upcoming changes in the next release which users can test out and provide feedback on.
We also blog on the Esri Community with what's coming blogs, such as the https://community.esri.com/t5/arcgis-survey123-blog/what-s-coming-in-arcgis-survey123-september-2021....
The other place to find the what's new changes is in the online documentation, but this is only updated on the same day the apps are released: https://doc.arcgis.com/en/survey123/faq/whatsnewsurvey123.htm
Regards,
Phil.