nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Katie_Clark

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!

Find more posts tagged with

Accepted answers

ZacharySutherby

Hello @Katie_Clark,

Please see this documentation for reference.

All comments

ZacharySutherby

Hello @Katie_Clark,

Please see this documentation for reference.

Katie_Clark

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)"

dougbrowning

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.

dougbrowning

Probably globalid, editor tracking, shape, objectid, etc

Katie_Clark

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. 🙂

abureaux

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.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.