Creating a Form is slow & does not publish with this survey

865
6
Jump to solution
09-25-2017 10:15 AM
RenatoSalvaleon
Occasional Contributor III

I've been having some challenges trying to publish this form.  Its a QA form and when its finished it will include about 60 x 15 questions (six are esritype::null).  The number 60 represents sixty tables to be QC'd separated by groups in the survey. The survey will be used by a QC analyst and on each group there's two select_multiple list which are pre-populated from the choices worksheet.

I automated the creation of each group of questions into a temporary csv table. From this csv I copy and paste each grouped questions to the survey xlsform, incrementing the process one group of questions at a time. As I add a group or questions, I save the xlsform, test and then publish. (Note: This iterative process created multiple feature layers for each publish. At some point I started deleting duplicates, retaining only the last FL from the most recent successful publish)

After going through the iterative process 18 times, the publishing stopped working. Creating form will progress bar will stay in the middle and then after 15-20 minutes will get to the end and it just stay there until I terminate.

I'm attaching my last successful excel file (1_QA) that was successfully published and the version that where failure started (2_QA) . attribute_count.csv is an external choice csv for both.

We use Portal for ArcGIS 10.5.

Any ideas to troubleshoot or fix are welcome. Thanks!

0 Kudos
1 Solution

Accepted Solutions
JamesTedrick
Esri Esteemed Contributor

If there number of features per table is dynamic, then the extended form will not work- that is more for just addressing long lists of questions on one form.

I suggested creating a generic component inspection repeat because it appears that the question for each component are largely the same.  I would have a repeat with the following questions:

componenttype

componentcount
componentnd
componentd
componentnd
componentd

componentype would have the list of components, and then the remaining questions are the ones in the repeat.  You would lose the sum by component questions that are in each group, but this makes for 1 table to query/analyze, as opposed to 60 and the sum by type analysis can be done after submission.

View solution in original post

6 Replies
JamesTedrick
Esri Esteemed Contributor

Hi Renato,

I'm able to publish successfully.  Have you trie to publish the failing form as 2_QA (or another new name)?  I think perhaps part of the problem is the iterative publishing process- it may have provided an opportunity for something to get 'stuck' with the name of the table you're using.  I'd try renaming and publishing when you've completed the form.

The 

RenatoSalvaleon
Occasional Contributor III

I followed your suggestion and it did not work for me. I am in the tedious process of publishing a service for each of the table to validate the form, field names, schema and see if it publishes. So far out of the sixty, I'm halfway and each form published successfully. I'll merge groups of twenty later and see if it works. The biggest concern I have is size of the form - questions and the choices. But I've seen comments on the forum which has far more excel rows than Even if I merge all these sixty tables together I'll still be below the 500 question limit of Portal. While the nulls show up on the schema I assume publishing ignores them, right.

Do you have any suggestion on what to look for in the diagnostics why the form is not being created?

0 Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Renato,

I missed the portal the first time I attempted to reproduce - I am able to see the problem with Portal.  The error I'm getting from the the Data Store is an unusual one.  I think it might be likely that you're running into an issue of one part of the publishing process taking longer than expected given the size of the number tables you are creating and a second step failing because the first has not completed.  

I would also point out that these results are going to be somewhat ungainly to access- you might want to think about revising the structure of the survey, either as one for (extended by using a repeat with repeat_count of 1) or by having a 'component inspection' repeat that is generic for all components - both would be a bit more efficient in terms of data access.

In terms of diagnosing, the first thing I do is generate a log file during the publishing process.  For more detail,you ca also review the data store's log files - Access and manage ArcGIS Data Store logs—Portal for ArcGIS (10.5.x) | ArcGIS Enterprise 

RenatoSalvaleon
Occasional Contributor III

I thought I was getting lucky by publishing one table at a time and then copying the successfully published sections in to a merged survey until I got to table number 16 where I started going through the same error. I wonder if it is a coincidence with my first bigger merge that it started failing at table 16. I wonder if 15 is a magic number of related tables. I'd really hate repeating the whole process though.

Can you please rephrase what you mean by: " either as one for (extended by using a repeat with repeat_count of 1"? If I understood this correctly you are assuming that for each table there is only one feature count. The number of features per table is dynamic.

For the second one, how can a 'component inspection' be reused as a group question for each table? Is there an available samplthat you have in mind?

0 Kudos
JamesTedrick
Esri Esteemed Contributor

If there number of features per table is dynamic, then the extended form will not work- that is more for just addressing long lists of questions on one form.

I suggested creating a generic component inspection repeat because it appears that the question for each component are largely the same.  I would have a repeat with the following questions:

componenttype

componentcount
componentnd
componentd
componentnd
componentd

componentype would have the list of components, and then the remaining questions are the ones in the repeat.  You would lose the sum by component questions that are in each group, but this makes for 1 table to query/analyze, as opposed to 60 and the sum by type analysis can be done after submission.

RenatoSalvaleon
Occasional Contributor III

This solution is perfect for the cascading multiple select list in to a select one question. Is that functionality near the top of the queue yet?

My survey is almost done and it works with the publishing now. Thanks James!

0 Kudos