SQL Server feature layer skipping object id's - causing order of repeats to get messed up when editing a survey response

[j-bromp]

Hi there,

I recently migrated the feature layer that my survey points to to SQL Server. Since then the object id's have been jumping around all over the place. this was not really an issue until i noticed that when editing a survey, the repeats seem to become ordered by their objectid and not by the order they were recorded in. I guess the survey loads in the features in the order they are in the table (which is ordered by objectid).

For example:

1. submit survey with two repeats with names A and B (repeats receive object id's 1012 and 1013)
2. edit survey and add a third repeat named C (receives object id of 412)
3. edit survey again - repeats are now ordered C, A, B

this is a big no no as i have repeats that reference each other in comments and affect calculations across repeats by indexing, so the order of them is important. does anyone know a solution to this?

Cheers

[j-bromp · Accepted solution]

ok have figure it out, if anyone else runs into this issue - have a field that collects some sort of order either a field that records the position(..) or a time field that defaults to now() for each repeat. then in the bind::esri:parameters column for the begin repeat row have orderByFields=your_field
this then overrides the default ordering by objectid.