"Error 1003: Operation rolled back" on new version 2.7.98 but works in 2.5.44

TregChristopher · ‎05-09-2018

Published a from in Connect v2.7.22, I hadn't updated the user version though, so when I submitted dummy record it worked fine in app v2.5.44.

Then a user reported the rollback error and so when I downloaded the latest version (2.7.98) to both my phone and desktop, I got the same rollback error.

Is there a reason this will work in an older app version but not the latest? I've seen previous post on this error msg and it was related to data type mismatches or possibly some network issues. Is it possible that the newer version is less-lenient and so some mistake that I made in the data or form structure was previously getting thru but now can't with the stricter implementation in v2.7.98?

TregChristopher · ‎05-11-2018

Hello,

Issue has been resolved. This was NOT related to the error code (1003) explanation "This can occur when a survey has hidden or calculate fields with the wrong data type." but rather related to a nullable=false field in the feature service (published from a feature class not from S123) that wasn't being populated with a value (even though a default value was set in the form).

Details:I have a 2-page survey with the 2nd pg only showing if there were animal detections="yes" in the 1st pg.The latest version failed when I tried to submit a survey with no detections (2nd pg doesn't show) and there were required fields in this 2nd pg. These required fields (both integers with domains and a select_one form type) were set to a default value (999="NA") so that the form should get submitted successfully even when the 2nd pg was hidden.

The problem was that two fields didn't keep the default value in the results (several other fields of both hidden and select_one types did have default values that were retained in the results). With the old app (v2.5.44), the form went ahead and submitted but the results showed a "0" in the two fields (i.e. not retaining the 999/NA value). The new version (2.7.98) seems to be stricter, and so the record could not be submitted.

Solution:This feature service was originally published from a feature class (not created from S123) and one of these two 'problem' fields was required (nullable = false). I deleted the field from REST-admin (because nullable can't be changed here), re-added the same field but with nullable=true. This still didn't resolve the issue of why default values weren't working for 2 fields but were working for other fields but I have a workaround, so that's as far as I can take it now.

View solution in original post

BrandonArmstrong · ‎05-09-2018

Hi Treg,

Please take a look at the following and see if it might apply...

http://doc.arcgis.com/en/survey123/desktop/get-answers/troubleshootgetanswers.htm#GUID-5F4B8836-7338...

If not, can I ask how you have shared your survey? Is it via a Group?

TregChristopher · ‎05-11-2018

Hello,

Issue has been resolved. This was NOT related to the error code (1003) explanation "This can occur when a survey has hidden or calculate fields with the wrong data type." but rather related to a nullable=false field in the feature service (published from a feature class not from S123) that wasn't being populated with a value (even though a default value was set in the form).

Details:I have a 2-page survey with the 2nd pg only showing if there were animal detections="yes" in the 1st pg.The latest version failed when I tried to submit a survey with no detections (2nd pg doesn't show) and there were required fields in this 2nd pg. These required fields (both integers with domains and a select_one form type) were set to a default value (999="NA") so that the form should get submitted successfully even when the 2nd pg was hidden.

The problem was that two fields didn't keep the default value in the results (several other fields of both hidden and select_one types did have default values that were retained in the results). With the old app (v2.5.44), the form went ahead and submitted but the results showed a "0" in the two fields (i.e. not retaining the 999/NA value). The new version (2.7.98) seems to be stricter, and so the record could not be submitted.

Solution:This feature service was originally published from a feature class (not created from S123) and one of these two 'problem' fields was required (nullable = false). I deleted the field from REST-admin (because nullable can't be changed here), re-added the same field but with nullable=true. This still didn't resolve the issue of why default values weren't working for 2 fields but were working for other fields but I have a workaround, so that's as far as I can take it now.