Best practice question: upper limit to number of rows in XLS form

734
6
Jump to solution
02-17-2023 11:11 AM
Katie_Clark
MVP Regular Contributor

Hello,

I am wondering if there is a recommended best practice for an upper limit to the number of rows to include in an XLS form for a survey. For some complex surveys, with a lot of conditional questions and even entire sections, I've found it's pretty easy to reach several hundred, or even over 1,000 rows at times. 

Any advice or "lessons learned" stories to share on this topic?

Thanks in advance!

Best,
Katie


“The goal is not simply to ‘work hard, play hard.’ The goal is to make our work and our play indistinguishable.”
- Simon Sinek
0 Kudos
1 Solution

Accepted Solutions
ZacharySutherby
Esri Regular Contributor

Hello @Katie_Clark

Please see this documentation for reference. 

Thank you,
Zach

View solution in original post

6 Replies
ZacharySutherby
Esri Regular Contributor

Hello @Katie_Clark

Please see this documentation for reference. 

Thank you,
Zach
Katie_Clark
MVP Regular Contributor

Thanks @ZacharySutherby ! Sorry I missed that in my initial research, I wasn't using the right search terms I guess. Appreciate your quick response!

A silly question maybe, but can you clarify what is meant by "system fields" in the FAQ? 

"a survey can contain a maximum of 1,024 columns (including system fields)"

 

Best,
Katie


“The goal is not simply to ‘work hard, play hard.’ The goal is to make our work and our play indistinguishable.”
- Simon Sinek
0 Kudos
DougBrowning
MVP Esteemed Contributor

Probably globalid, editor tracking, shape, objectid, etc

DougBrowning
MVP Esteemed Contributor

I think with the new calculation engine you can really push it up there now.  I go over 400 on the reg.  In the past we would run out of memory and the form would close, esp when hiding a lot of relevants.  Its better now but it can happen.  Using visible also helps.

We do break them up for the user though.  We have 1,700 fields total but made it 12 forms since that fit more logically with the workflow.  Plus then we could have multiple crew members working on different forms on multiple tablets at one time.

At over 1,000 fields you may start to confuse the user though.  That is a lot to get through.  Plus if the app or tablet crashes that is a ton of lost work.  Using the attribute table in AGOL will also not be fun.  Next enterprise geodatabases are limited to 500 fields which will cause issues if you processing into SDE permanent storage like we do.  (https://desktop.arcgis.com/en/arcmap/10.7/manage-data/geodatabases/enterprise-geodatabase-limits.htm )  Regular GDBs can do 655,000+ fields but what a pain to use!

I try to always put photos in their own form.  We take up to 19 and it can be a huge upload.  This way the user can upload all but photos if they are on a bad connection.  Also my nightly backup script tends to crash when the service gets over 10 GB (I have an open bug on this) so I tend to backup all layers but photos.  The tablet cameras are getting huge now.

Great question hope that helps a bit.

Katie_Clark
MVP Regular Contributor

Thanks, Doug! With the form I'm currently working on, it's getting fairly large because the user specifically requested that everything be contained in one survey so the end-users would "only have to worry about the one survey". I wanted to accommodate and it seemed simple enough at first, but as I've dug in a bit more it's become much more cumbersome. My main concern is simply managing that many fields in a single feature layer within AGOL.

I really appreciate you sharing your experiences and advice! Very helpful. 🙂

Best,
Katie


“The goal is not simply to ‘work hard, play hard.’ The goal is to make our work and our play indistinguishable.”
- Simon Sinek
abureaux
MVP Regular Contributor

I have some rather long surveys. Performance on them isn't too bad. Performance starts to take a dive when you add a lot of repeats. My laggiest survey has over 40 repeats, and can take 30 seconds to open. It's not the most fun to work with.

0 Kudos