Collector for Android Bug - Copy feature that has attachment
I'm still working with support, but I'm posting in case anyone else sync problems that could be due to this issue.
The bug occurs when I use continuous stream or copy features that have photo attachments; in other words, "Like the last one" functionality.
- My features are displaying the same attached photos. Sync Fails.
- If i delete one they both lose all photos. Sync Still Fails.
- If I delete all features. Empty Sync Succeeds.
Here are images of the 1st and 5th test feature i took. for each feature i copied the previous and attached a photo via camera. but the 1st feature shows the attachments collected on the later features.
Here is what happens on the 1st sync attempt
During second attempt, the progress bar quickly moves to 99% but hangs indefinitely.
.png)
Details:
10.3 version of Collector on 2 different Samsung Tab 3 7" and a Samsung S5
Reproduced in 2 different web maps with same hosted layers
Arcmap's Copy Runtime Geodatabase to File Geodatabase tool produces features with duplicate attachments.
Could not reproduce in different hosted layers in separate web map. The attachments were not carried over when copying a feature
Initial download for offline mode has no issues
I'll update when this gets resolved.
Well I solved it and this is indeed a bug. The feature service in question was republished and was given a new field for GlobalIDs. So it has a string field named "GlobalID" and an esriFieldtypeGlobalID field named "GlobalID_2". Copying features also copies the value that should be unique! This is why the first feature that is copied has the photo attachments of future features.
Perhaps other sync issues are related to this failure to generate unique IDs.
Be careful what your users copy!
Edit: I read something interesting about copying with relationships:
- When you split a feature, the original feature is maintained (with updated geometry), and a new feature is created. If you have a relationship based on the original ObjectID, only one of the two features created in the split will maintain the relationship. However, if you used another field as the key, when you split the feature, the ID value of the original feature would be copied to the two new features. As a result, the records in the related table would now be related to both new features—ideal if the relationship class is set up as many-to-many.If you won't be splitting features and are sure that all objects will remain in their original class, you can use the ObjectID as their IDs. If you can't guarantee this, it's best to set up and use your own ID field instead of relying on the ObjectID field.
