autocomplete box fails in 4.12 unless pulling from a table

Essentials: 4.12, Viewer 4.12.1, also tested with 4.12.2

 

We recently upgraded from 4.9 and 2.10.1 to 4.12. There were a few issues introduced with 4.12.1 (not relevant to this post), so I also have a test machine with Viewer 4.12.2 available. The behavior described below is occurring in both viewer versions. We do not have any public-facing sites for external testing (sorry).

I have a workflow that begins with a simple form that has two autocomplete boxes. For this example, say that the first autocomplete box is names of lakes and the second is names of mountains. Before the upgrade, both were working fine and had been in use by general users with no issues. After the upgrade, the mountains autocomplete still populates as it did before, but the lakes fails. It just spins (the 3 vertical marks on the right fading in and out) endlessly. If I enter a value I know is valid, the workflow works just fine - it seems to only be the autocomplete aspect that is having trouble. The two boxes are populated with data from the same service; the only difference that I know of is that the mountains list of matching names comes from a table, whereas the lakes list of matching names comes from a feature class. All the data is in our Oracle database.

When I exported the attribute table from the lakes feature class into a stand-alone table (outside of Oracle), published a new service with the extra table added, and used that table to populate the lakes autocomplete box, it started working again. I was able to reproduce this repeatedly by switching the map service information back and forth between the table and feature class service layers. 

Is this a known bug? Can anyone else reproduce it? It's not terribly hard to work around in our particular case, but we do end up with multiple datasets that have to track together (there are other workarounds for this too, but that's a different topic). Ideas?

Thanks,

 

Jena