Setting up a repeat to an existing table in an existing feature service

[TylerGraham2]

I'm testing a new form for some of our monitoring activities. One of the things we need to track is relevant conversations with people in the field (e.g. Bob said work is cancelled so you can go back to the office). This needs to be a repeat field in the form because there can be multiple conversations that take place during the day. I set the table that will be the destination for the repeat with the name "field_convos" and an alias of "Field Conversations." I published it as a feature service using Pro and set up the survey responses in Connect.  I gave the repeat the same name as the table; "field_convos." When I tried to publish my form with the repeat titled "field_convos" and I got the error "The custom feature service submission_url is not compatible with this survey. Table field_convos not found." 

I removed the "field_convos" repeat and tested my other repeats that point to other tables and received the same error when I used the name of the table from Pro. I took a look at the feature service table names in AGOL and saw that the names of the published tables were the aliases from Pro. All of my other repeat tables had one word aliases and when I changed from the table name to the alias name (e.g. "photos" to "Photos") it resolved the error for those particular repeats. 

However, when I tried to change "field_convos" to "Field Conversations" in the name column of the xlsx I get the message in Excel that it is an invalid name because of the space in it. Since I have no data in yet, the most obvious solution is to republish my feature service with an underscore instead of a space for the alias, but that defeats the purpose of setting an alias.

Is the only way to setup a repeat with an existing table to use the published table name, or is there another way to point the repeat to that particular table?

[DougBrowning]

Yes the Name column on the Begin Repeat line needs to match the name of the table in the feature service you are linking to exactly.  That is how it knows where to put the data.  Make sense otherwise how would it know.

With repeats you will need to add a parentglobalid field to the children if you want 123 to manage that for you.  Otherwise you need to update the keys in your form.  Many of us have the parent and child key the same field name but that will get you in the form.

If you are talking about the parent level then the form_id on the settings page needs to match the layer name in the service.

This post may help also https://community.esri.com/t5/arcgis-survey123-blog/survey123-tricks-of-the-trade-repeats/ba-p/89804...

Hope that helps

[TylerGraham2]

Thanks Doug. I did have all that figured out. The root cause of the problem is that the name column in the xlsx won't accept spaces, but Pro publishes the layers and tables using the aliases set in the geodatabase for the hosted names, which can have spaces. The two are incompatible, so I was looking to see if there was an alternate way to get the repeat to reference a table with spaces in the name.  It looks like there isn't. I've already republished my service without spaces in the table aliases and it works fine. I'll just have to live with getting a little salty whenever I need to add a space to the table names to make a polished product for consumption. 

[DougBrowning]

You got spaces in your Table Names?  I thought that was not possible.  The alias can have spaces but that is not what 123 would match to and it is not what is in the service.  All my services have spaces in the alias without issue.  It may show you spaces in the display but the backend is prob not and changes to _ usually.

For ArcGIS to work with multiple data types, certain characters in field or table names are not supported. These characters include spaces, hyphens, such as in the term 'x-coord', brackets, and other special characters.
https://support.esri.com/en-us/knowledge-base/faq-what-characters-should-not-be-used-in-arcgis-for-f.... 

[TylerGraham2]

Here's some screenshots of what I've got, the feature class and table names in the database have no spaces, but the aliases do. When I publish to AGOL as a feature service the feature layers and tables all come in with the alias as the name, spaces and all. I opened the REST for the field conversations and the hosted table name has a space in it. 

[DougBrowning]

I think it is just showing you the alias.  The real name probably has no spaces.  Scroll down the rest page and hopefully you will see it.  In theory it would match the names as you published them.  I have not really seen this before but I tend to have the alias the same.  123 but be grabbing the wrong name.  Convert those to the way you published them with the underscore and see if that does it.

[TylerGraham2]

I've tried "field_convos", the name of the table in the database. I've tried "Field_Conversations" with the underscore, I found there was an space at the end of the name in this test version that I'd published, so I ran through trying "Field_Conversations_" and "Field Conversations ". I even dug into the JSON and tried some variations of the tableName property with no luck.

"tableName" : "db_2884.user_2884.ARCHAEOLOGYTESTS123_FIELD_CONVERSATIONS_"

"name" : "Field Conversations ",

I think the tableName property is the actual name of the table and the name property is functioning as the table alias. The only thing that worked for me was republishing the database without spaces in the aliases of the tables. The repeat has to match what is in the hosted table's name property in order to work, which it can't do if there's spaces. I think I need to submit a bug report for this.   

[EKulack]

I'm having this same issue as you with the alias, and it has been very frustrating to figure out. Thanks for helping with that.