fileName inconsistency

[trashbaby]

Hello,

I am assigning unique fileNames to a multiline image question that consists of a concat of different fields previously completed in the survey.

I'm experiencing an issue where the first image will be named according to the default multiline image naming convention, but the second image will named according to the fileName I've assigned. Sometimes even on the third image the unique fileName will kick in, but the first two were assigned the default image name.

This phenomenon is occurring in S123 Connect as well as the mobile app.

Any insight into this would be appreciated!

[abureaux]

Could you provide your XLSX so we can see how the calculate is set up?

[trashbaby]

Hi abureaux,

XLS is attached.

[abureaux]

Your template was rather outdated, so the first thing I did was update it to the most recent version. Normally, you can do that with Tools > Update XLSForm template, but I had to do it manually for this one.

Since the template was so old, I next ran Tools > Analyze survey, but still got an error.

After some trial and error, I realized that there were invisible characters in some cells of the first few rows of the document:

After removing those, the tool ran successfully. It was while I was searching for these invisible characters that I also realized that you had some malformed content. E.g., this select_one is missing an underscore:

Most of the content in the analysis is minor, but one thing of note is that list_material_categories had duplicate choice names. This should be corrected.

I have attached the update XLSX. If you are still using an older version of Connect, I would suggest you update that as well. Use the Microsoft Store version as it auto-updates.

With that out of the way, I had a look for the calculates. I am assuming you are referring to lines 42-47 and 63-76. I took several photos, and everything seemed to work well:

1

2

3

4

I did make one addition to your document: sample_date_calc. If you reference a date field, you will get the UNIX time rather than human time (feel free to change the format to whatever suits you best):

vs

[trashbaby]

abureaux,  your response is ENORMOUSLY helpful. i was hitting a wall and could not figure out what was going on with my limited ArcGIS/S123 experience. I was so close, but there was no way I could have figured these issues out on my own.

I had made a separate post about the data formatting, so even your afterthought feedback on the UNIX time was spot on. I was so stuck on the date formatting as well. Knew it was showing up as UNIX but could not figure out how to format it. That works now.

That said, the image filenames were working, but then the same issue occurred. The first 2 or 3, or even 4 images are named according to the default naming convention (sample_photo2-date-time) but the custom file name will kick in after several images, like the 5th or 6th. I did rename some of the Sample Photo section images as I noticed they all had "source" rather than the name of that photo type (source photo, Sample photo 1, etc). And it worked after I did that. But now the issue again...and it's really inconsistent with how it occurs.

My Connect version is 3.19.104 FYI.

I attached the XLS that includes these small edits.

[ChristopherCounsell]

Here are some rules to properly set the file name:

• Avoid spaces and the following special characters: \ / : * ? < > ; | . , ".
• The file name must be unique: Otherwise, you will have trouble either attempting to upload, or when you download the file in the future.  
• Keep file names under 140 characters

If you do not follow the rules above, the Survey123 mobile and web apps will override your file name with one that complies with the rules.

https://community.esri.com/t5/arcgis-survey123-blog/survey123-tricks-of-the-trade-set-the-file-name-...

Your filename calculation is this:

fileName=concat(${facility_code}, "-", ${sample_date_calc}, "-", ${outflow_code}, "-", ${sample_replicate}, "-", "source_photo", "-", ${img_count_source})

The sample date calculation is this:

format-date(${sample_date},'%m%d%y')

A date of 012624 is not going to be unique if both photos are submitted on the 26th Jan 2024.

To ensure unique photo filenames, you should put a timestamp with minutes and seconds directly within the filename parameter like this:

fileName=concat("Photo_",format_date(now(),"%y%m%d%H%M%S"))

Otherwise submitting photos on the same day will hit the limitations per the above. There may be other behaviour going on within your survey as there's lot of questions and calculations. For example, if the calculations are passing in and of \ / : * ? < > ; | . , ". you will also get the filename overridden.

[ChristopherCounsell · Accepted solution]

After commenting I see the extra logic in trying to count the photos and then calculate the filename based off the current count of photos.

Is this a strict requirement? Placing aside if in theory it will work or if it's the current cause of the issue, I'm not sure if this is the best survey design approach. It's a lot of looped calculations with a lot of photo questions. Could throttle the survey performance a bit. We've had users camera crashing on older devices when the multiline image question gets up to 8-10 for some surveys.

If you can, I'd suggest abandoning the idea for something simpler like question name + timestamp

[trashbaby]

Hi Chris,

I appreciate the thorough responses. 

It's not a strict requirement to have the image names titled as such, that was more so for my own organizational preference. As long as each image name is unique and can attributed to that specific survey. 

I will play around with different fileNames to find something simpler. Because of the inconsistent way in which the issue occurs, it does seem that the image count and looped calculations may be the cause of the issue on the back end.

It's very strange. In the same image field, sometimes my custom fileName applies with the first image, and sometimes the first two are the default filename, and my custom name kicks in on the third. There's no patten that I can discern.

Thanks again!