topic Edit Application - sometimes edits don't save in ArcGIS Enterprise Questions

Edit Application - sometimes edits don't save

AdamMills — Tue, 25 Feb 2014 16:33:52 GMT

I wasn't sure if I should post this in the ArcGIS Server or Flexviewer forum, so I chose to start here:
ArcGIS Server 10.1
Flexviewer source code version 3.6 utilizing "out of the box" edit widget
SDE 9.3 - two feature classes with approximately 100,000 features to edit (minor attribute edits, maybe 4 - 5 columns)

We have a couple of versioned (move to base enabled) feature classes that our users are editing on an internal flexviewer application. At first, everything worked perfectly. Then the problems started - users were complaining that the feature classes were getting updated on screen, but when they checked them the next day, they had reverted back to pre-edit. My colleagues and I researched it and found some erratic behavior. We weren't able to R&P at first, so when I finally did I found over a million records in the state lineages table. It took a couple of hours to clean up with the compress and now we R&P and compress every night. I thought this would fix the problems, but users are still complaining.

Could the 9.3 SDE be the problem? Maybe domains are an issue? Too many features? Any suggestions or ideas for the ideal web editing environment would be greatly appreciated.

thanks,
-Adam

Re: Edit Application - sometimes edits don't save

WilliamCraft — Tue, 25 Feb 2014 23:49:16 GMT

Quick question: Which version is your Flex Viewer connecting to (the parent or one of the child versions)?

If you are seeing behavior whereby edits have been reverted back to "pre-edit" as you describe, my first thought is that you should review how you are reconciling and posting from child versions up to their respective parent(s). Make sure that when you reconcile you are doing so in favor of the correct version. Could you provide more information about how you are doing rec/post?

Re: Edit Application - sometimes edits don't save

AdamMills — Wed, 26 Feb 2014 14:40:41 GMT

It's referencing/editing the one and only child version. My thinking is this way they will see the change (almost) immediately and wouldn't have to wait on rec&post. We r&p/compress nightly now and since it only has one version conflicts should not be an issue.

thanks,
-Adam