Slow editing in 10.1

RobbHodges · ‎06-22-2012

I've been having issues when editing a version 10 geodatabase in ArcGIS 10.1 from the network. Editing a version 9.3 seems to be fine. With ArcGIS 10, I was having zero issues editing from the network. Basically, selecting anything has a noticeable delay. Moving anything results in at least a 10 second delay. Editing the same data on my local results in zero problems.

I called tech support and they initially blamed it on the network. Well, 2 days prior, it worked fine on the same network. There were no changes made to the network, only to the upgrade of version 10 to 10.1. We then tried renaming the normal.mxt and the esri folders in the registry. That didn't work either.

Has anyone experienced this in 10.1? It's a bit frustrating, because we really need this to work from the network. I am editing on my local right now as a temp fix, but eventually that won't work.

Thanks,
Robb

MichelleBoivin · ‎10-28-2013

Out of curiosity, has anyone on this thread tested or upgraded to 10.2 and attempted any of the above? Is 10.2 having the slow editing issue (or any other major issues for that matter)?

RobbHodges · ‎10-28-2013

In our case, it was a matter of our server. We were storing all of our GIS data on an older linux based server. We've since moved everything over to a newer windows based server and have seen speed dramatically increase (not just in GIS, but across the board).

ClintRichmond · ‎10-29-2013

I have spent several weeks working on our slow editing situation. We are on 10.1 with direct connection to SQL Server 2008 R2 on a VM. I discovered that our issue involved database authentication. When I switched over to operating system authentication, editing became lightning fast.

MichelleBoivin · ‎11-08-2013

I've been having issues when editing a version 10 geodatabase in ArcGIS 10.1 from the network. Editing a version 9.3 seems to be fine. With ArcGIS 10, I was having zero issues editing from the network. Basically, selecting anything has a noticeable delay. Moving anything results in at least a 10 second delay. Editing the same data on my local results in zero problems.

I called tech support and they initially blamed it on the network. Well, 2 days prior, it worked fine on the same network. There were no changes made to the network, only to the upgrade of version 10 to 10.1. We then tried renaming the normal.mxt and the esri folders in the registry. That didn't work either.

Has anyone experienced this in 10.1? It's a bit frustrating, because we really need this to work from the network. I am editing on my local right now as a temp fix, but eventually that won't work.

Thanks,
Robb

Robb et al, 😮

We just finished running some additional tests on our side per ESRI's request (we had our PM from ESRI on the phone looking at exactly what was happening - sluggishness, etc.) They suggested setting up a separate database on the same box (in our case Production), and changing the data storage back to SDEBINARY rather than GEOMETRY (ESRI's default). Once we did and tested while editing with numerous users for 1.5 hours, we saw an improvement. I then went back to our Production data, backed up the new geometric networks, recreated them, and then imported the data using the SDEBINARY config keyword. When I came in this morning, PERFMON (or the performance on the server and on Desktop) have vastly improved to where I am actually happy and satisfied with the outcome. We are still continuing to review the situation and make sure it stays this way.

We did not have to change the data types for all of the data in the Production database, but just the networks that were giving us the problem, so we can still have the SQL Server functionality for 98% of our data in the database. It appears that ESRI has not yet caught up to the SQL Server storage types with their more advanced networks or data types.

Hopefully this will help some of you as I know it has been VERY trying here, but as I mentioned, we have noticed a significant difference in our data and our editing.

Cheers,
Michelle

MichelleBoivin · ‎11-25-2013

As we are continuing to work on some issues mentioned above, ESRI has emailed us the following regarding performance issues when using SQL_Geometry:

http://support.esri.com/cn/knowledgebase/techarticles/detail/38871 (Our (ESRI's) kb article on bug)
-discusses issues on a multiproecssor system and a bug in MS' query optimizer. Their fix is in SP2 - only problem is we are already on SP2......
http://support.microsoft.com/kb/2570501 (MS kb article on bug)
-speaks to the parallel query against a large spatial table
http://support.microsoft.com/kb/2591748 (specifically mentioned in this fix)

Suggest having a DBA take a look and run a trace to document the issues.

~Michelle

jennifergordon · ‎12-26-2013

Ever since we've gone to 10.1 with the direct connect we've had nothing but problems. We've had multiple duplicate key errors and countless snapping issues. The snapping will just at times quit working all together, but strangest we've encountered is snapping issues with a large lake layer. It's located on the SDE and anytime a person goes to edit it the snapping gets killed until a compression is done. I would get it if we did a lot of edits, but all it takes is moving one point in this file and snapping dies for every other layer until a compression is done. We have very few people that look at the layers on the SDE and only two edit on it but we need it to work. Before we upgraded from 10 to 10.1 it worked fine. We have moved several points but haven't really added many so the file size hasn't changed much from then to now.

FreekBusschers · ‎02-12-2014

Dear all, we're (and 20 of my collegues) also experiencing dramatic editing sessions. Adding or moving a node takes ages. This was not the case in 9.3. We've reached the point of ''not workable anymore''. Can anyone tell me what's the latest conclusion on this topic? Is it a network configuration that we have to change or something else? Is shape caching not a solution?

Cheers, Freek, the Netherlands

BillLotz · ‎03-24-2014

Same problem here. Editing features over network in a SQL 2008 R2 database, and ESRI 10.2. Direct connect OS authentication. Can turn of snapping and it still hangs. Editor can be editing fine, but then selects a line and it just spins for a minute, then finally selects.

MichelleBoivin · ‎03-24-2014

knoxgis & fsbusschers, if you have a test environment or some movement in your Production environment, 1) make all layers binary rather than geometry that participate in the geometric network 2) rebuild the networks, 3) begin editing. We saw a drastic improvement in editing with the geometry change. This was also confirmed by the ESRI consultant that was out here working with us. In addition, make sure no one is editing default (we never think folks are, but some do). That weighed in on the editing lag as well. However, the change in spatial storage type was the largest difference of all.

~Michelle

MichelleBoivin · ‎03-24-2014

Also, something else they mentioned was installing SP2 for SQL2008R2 which included a MX hotfix for spatial indexing in SQL and then setting the traceflag to 4199. This also worked for us. It is included with SP2, else you have to install the Hotfix separately for previous versions. Below is the traceflag URL http://support.microsoft.com/kb/974006. In addition, here is the URL for the Microsoft Hot Fix (2008R2) http://support.microsoft.com/kb/2570501.

Please feel free to email me separately for any questions. We have exhausted a lot of time trying to get to the bottom of this issue and have finally gotten to where we can function properly, although not optimally.

Cheers,
Michelle